How can I lay down a directory structure with file resources (and create docker volumes) to create a deployment?

[Steve973]

Hello. I am trying to figure out how to use a bundle to write a directory structure and resource files to a host file system. It seems like this is something that would be customary, but I am either misunderstanding something, or I cannot find documentation or examples of how people are doing this. Note that I will not be deploying to kubernetes. I will be performing either a single-node docker-compose setup, or I will be using docker in swarm mode. Or, both, depending on the deployment.

Let's say that, for my use case, I have a Spring Boot application, and I am using elasticsearch and mongodb. For all three containers, I will need config files: application.yml for the spring boot app, mongo.conf and some configuration for es. I will also need data volumes for mongo and es. So, a complete deployment solution would allow me to create the directory structure and files that I need, and the ability to create docker volumes for those directories and resources on the host filesystem. Is that something that porter/cnab can do? Or, am I thinking about this in the wrong way? I am at a complete loss at the moment.

[vdice]

Hi @Steve973, excellent questions. I'll help as best I can.

Currently, Porter doesn't support a mechanism to modify the filesystem on the host that is executing a bundle (as far as I'm aware). Of course, files/directories from the host can be added to the bundle execution environment (a Docker image) at build-time or passed in at run-time via parameters, but the execution environment doesn't have permissions/volume mounts for creating/modifying assets on the host.

The exception is when using the docker or docker-compose mixins in tandem with the allow-docker-host-access extension. Even so, this just enables mounting the host docker socket into the bundle execution environment, so all interactions are limited by what the docker CLI(s) offer. Creation of Docker volumes on the host, when the aforementioned extension is enabled, should be possible. However, any application assets that were baked into the bundle execution environment wouldn't be accessible to the host's docker daemon if they didn't already exist on the host running the bundle -- and thus not available to the containers constituting the docker-compose setup.

I regret to say that I am not experienced with Docker Compose beyond trivial/beginner examples, so there may be opportunities to support your use case via the above approach that I'm missing.

However, the following scenario should theoretically be possible: a Porter bundle is written such that it creates a VM (say, via a cloud provider's API) and proceeds to configure the VM with all the necessary assets/directories it needs (presumably utilizing/uploading assets that are available to the execution environment via method(s) described above), and then it runs a docker-compose up (or similar) command on the VM once everything is set up/staged. In essence, the bundle is laying down the host directory structure, etc., but via cloud API(s), rather than directly on the host that is executing the bundle.

Hope this is helpful and/or at least sparks more ideas/discussion!

[Steve973]

Thank you for taking the time to write such a thorough answer. Ok, this all makes sense with what I have experienced so far. If we are setting things up on a cloud infrastructure, it makes perfect sense, because you are only ever running in an image. I have a suggestion, though, that would also make it more convenient to deploy to a single server environment, like my use case.

What do you think about adding a feature that allows us to mount a read-write volume on the container in the invocation bundle? Perhaps it could be a parameter that we provide when we run the command line installer. With regular docker, the command docker run -v /path/to/host/install/dir:/installdir -i -t someimagename /command/to/run allows us to attach a volume when we create a container from an image, so it seems like it would be possible to expose this functionality. Then, when we invoke a helper script, we could write to the path within the container where we mounted the directory from the host file system.

What do you think?

[vdice]

(Oops, meant to reply in-line here... see second 'Answer' below.)

[vdice]

The approach suggested is definitely worth considering and I would envision the implementation being fairly straightforward (via a combination of Porter CLI flags/opts and perhaps a new, corresponding required extension), but in my opinion the crux lies in the security implications of this potential functionality. Opening the door to host modifications from a bundle's execution environment brings in a lot of attack vectors.

However, before going that direction just yet, I wanted to get your thoughts on a bit of experimentation I did today to re-familiarize myself with Docker Compose and see if there might be a way Porter can support your use case today without needing any new functionality.

I created the following sample bundle: https://github.com/vdice/porter-bundles/tree/master/wip/dockerapp. It has a few things going on:

• The Docker Compose setup consists of one single busybox-based "app" which uses a Docker volume for its data ("myvol")
• The helpers.sh script primarily features the setup of the "myvol" Docker volume and copies in both a file baked into the invocation image ("config.toml") and a file generated at runtime from a Porter parameter ("echo.txt"), the latter of which could have different contents depending on the user override. It uses a helper docker container to perform this data volume setup.
• The Porter manifest ties this all together, at least in the install step:
  1. Create the volume and populate it via a helper container
  2. Bring up the Docker Compose app
  3. Print the app logs

Do you think extrapolation of the techniques used in this sample bundle might cover your use case(s)? If we harness Docker volumes and "helper" containers to populate them with assets bundled or provided as parameters, we might be getting closer?

[Steve973]

• The Docker Compose setup consists of one single busybox-based "app" which uses a Docker volume for its data ("myvol")

• The helpers.sh script primarily features the setup of the "myvol" Docker volume and copies in both a file baked into the invocation image ("config.toml") and a file generated at runtime from a Porter parameter ("echo.txt"), the latter of which could have different contents depending on the user override. It uses a helper docker container to perform this data volume setup.

• The Porter manifest ties this all together, at least in the install step:

  1. Create the volume and populate it via a helper container
  2. Bring up the Docker Compose app
  3. Print the app logs

Do you think extrapolation of the techniques used in this sample bundle might cover your use case(s)? If we harness Docker volumes and "helper" containers to populate them with assets bundled or provided as parameters, we might be getting closer?

I haven't had a chance to try this out, yet. With the busybox helper container, its volume would have to be backed by a directory on my host filesystem so that the files could be written there. Today at work, I created an image that had all of my resources that I need to copy to the host, and I built in some conditionals to be able to select from multiple deployment types. I mounted a volume backed by my host file system, so I just wrote to that volume. That worked really well, although with the mixins that porter provides, I could do a good bit more to get the deployment to be closer to turn-key.

[vdice]

its volume would have to be backed by a directory on my host filesystem so that the files could be written there.

You could actually do this with a hard-coded host/source bind mount. When I update the example docker-compose.yml to the following:

version: "3.6"
services:
  hello:
    image: busybox
    command: ["sh", "-c", "echo Hello World > /data/log.txt"]
    volumes:
      - /Users/vdice/scratch/hostdockervol:/data

and run the bundle on my host, I get the generated log file:

 $ cat ~/scratch/hostdockervol/log.txt
Hello World

Granted, that makes the bundle not useful beyond running on my host...

But it could be cool to see about templating the host/source directory in the docker-compose.yml file so that a different value could be passed in as a bundle parameter! Then perhaps we'd have a more useful bundle...

[Steve973]

If we set up a volume with docker volume create -o device=/Users/vdice/scratch/hostdockervol docker-host-volume could you still use that in volume element of your service, like:

version: "3.6"
services:
  hello:
    image: busybox
    command: ["sh", "-c", "echo Hello World > /data/log.txt"]
    volumes:
      - docker-host-volume:/data

volumes:
  docker-host-volume:
    external: true

That would be 100% exactly what I am looking for, I think!

[vdice]

Oh, nice idea! I did get it working with:

docker volume create -o type=none -o o=bind -o device=/Users/vdice/scratch/hostdockervol docker-host-volume

The only issue: I couldn't get it to work if the host directory didn't already previously exist. (Docker didn't auto-create the host directory, as it seemed to do in the approach further above.) Not sure if this is problematic for the full automation scenario you had in mind...

[Steve973]

I think that could get us closer. And perhaps the directory for writing should have certain user/permission requirements, and maybe requirements for where the directory needs to be located. I understand the concern of security implications, but it's little different than mounting a r/w volume in any docker container; people would need to decide if they trust whomever publishes the bundle, because security provisions can only protect us to a certain extent in most cases. It should also be up to the person running `porter install` to provide the parameter that specifies the directory for the volume, so that they are aware of the behavior before proceeding. Thanks again!

…

On Tue, Jul 6, 2021 at 5:46 PM Vaughn Dice ***@***.***> wrote: The approach suggested is definitely worth considering and I would envision the implementation being fairly straightforward (via a combination of Porter CLI flags/opts and perhaps a new, corresponding required extension <https://porter.sh/author-bundles/#required>), but in my opinion the crux lies in the security implications of this potential functionality. Opening the door to host modifications from a bundle's execution environment brings in a lot of attack vectors. However, before going that direction just yet, I wanted to get your thoughts on a bit of experimentation I did today to re-familiarize myself with Docker Compose and see if there might be a way Porter can support your use case today without needing any new functionality. I created the following sample bundle: https://github.com/vdice/porter-bundles/tree/master/wip/dockerapp. It has a few things going on: - The Docker Compose setup <https://github.com/vdice/porter-bundles/blob/master/wip/dockerapp/docker-compose.yml> consists of one single busybox-based "app" which uses a Docker volume for its data ("myvol") - The helpers.sh script <https://github.com/vdice/porter-bundles/blob/master/wip/dockerapp/helpers.sh> primarily features the setup of the "myvol" Docker volume and copies in both a file baked into the invocation image ("config.toml") and a file generated at runtime from a Porter parameter ("echo.txt"), the latter of which could have different contents depending on the user override. It uses a helper docker container to perform this data volume setup. - The Porter manifest <https://github.com/vdice/porter-bundles/blob/master/wip/dockerapp/porter.yaml> ties this all together, at least in the install step: 1. Create the volume and populate it via a helper container 2. Bring up the Docker Compose app 3. Print the app logs Do you think extrapolation of the techniques used in this sample bundle might cover your use case(s)? If we harness Docker volumes and "helper" containers to populate them with assets bundled or provided as parameters, we might be getting closer? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1665 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD5JDW32QUFWYSN3QOMO4B3TWN2TPANCNFSM47YPANVA> .

[Steve973]

I didn't know that it would create the directory on the host with the first method you showed! But it's not a problem to ensure that it is created first. I wouldn't mind kicking the whole thing off with a minimal shell script that creates the install directory and kicks off porter.

…

On Wed, Jul 7, 2021, 7:50 PM Vaughn Dice ***@***.***> wrote: Oh, nice idea! I did get it working with: docker volume create -o type=none -o o=bind -o device=/Users/vdice/scratch/hostdockervol docker-host-volume The only issue: I couldn't get it to work if the host directory didn't already previously exist. (Docker didn't auto-create the host directory, as it seemed to do in the approach further above.) Not sure if this is problematic for the full automation scenario you had in mind... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1665 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD5JDWY4NIV7ZL4UQXYYTTLTWTR3XANCNFSM47YPANVA> .

[vdice]

👍 Awesome. Let me know how it goes! Excited to hear if this approach will work.

[vdice]

PS, I put up a similar bundle to the last solution we talked about (with a host bind mount volume), showing how the host volume location can be used as a bundle parameter, etc.: https://github.com/vdice/porter-bundles/tree/master/docker-volumes

[Steve973]

Do you think that this might be helpful as a blog post? Or, would it be good material, possibly, for a section on helper containers in the official documentation? I don't know how often people might want to do something like this, where they are trying to orchestrate a docker deployment or installation on the host, rather than on a cloud. What got me interested in Porter was the claim that you can install "anywhere", so that told me what I wanted to hear: that it could be used for non-cloud installations, too. I would be interested in hearing about other applications of helper containers, just to know what other things are possible.

[vdice]

I think a blog post around this scenario of non-cloud, host installations would definitely be useful. The majority of the posts/examples are definitely cloud-oriented, so there is plenty of opportunity to discuss other use cases.

I do want to note that for this particular exercise using Docker Compose and Docker Volumes, plus 'helper' Docker containers, Porter/CNAB isn't really doing anything special besides allowing the execution environment access to the host Docker daemon/socket. The Docker CLI(s)/toolsets are the ones doing all of the neat stuff here: data i/o, dir/volume mounting, application composition/coordination, etc. That being said, if combining all of these technologies helps show potential Porter users that their use case(s) are covered, it would be great to spread awareness.

Will be excited to hear how this approach works for you!