Hello all!

Can you mount any folder a docker image is running in?

So for example, if I have a python script creating a file “./hello.txt”, it would be written in the folder where I launch “docker-compose up” ?

I have figured out how to write the hello.txt to a subfolder like /data/ (by mapping an image-local folder to /data/), but I’d like to use like ./ for the image itself instead. So that the folder I’m launching the docker-compose in on my PC is mapped to ./ in the image, if that makes more sense.

So this works (in the compose.yml):

volumes:

  - ./:/data

but the script must write to “./data/hello.txt”

This doesn’t work:

volumes:

  - ./:./

It pops an error: mount path must be absolute

Any idea if this is even possible?

Cheers and thanks !

  • Admiral Patrick@dubvee.org
    link
    fedilink
    English
    arrow-up
    19
    ·
    edit-2
    8 months ago

    You’re close.

    ...
    volumes:
      - ./:/data
    ...
    working_dir:  /data
    

    That will mount your CWD to /data inside the container and then set the working directory inside to that.

    • Loulou@lemmy.mindoki.comOP
      link
      fedilink
      arrow-up
      2
      ·
      8 months ago

      Thank you !!

      One step closer :-D if I have the python file all ready to go in the directory, it works, but I can’t seem to use my binaries (or the python script) if I compile them in into the image only.

      I have my executables in a “binaries_to_use” folder, is there any way to add them to this local work folder? I tried the thing that worked before:

      COPY binaries_to_use/setup /

      but then

      CMD [“./setup”]

      doesn’t work, I guess it’s no longer a “virtual folder for the image” any more?

      Thanks again, I’m getting less dumb about this :-p

  • BrianTheeBiscuiteer@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    8 months ago

    Even if ./:./worked you want to be explicit with your container directories. . refers to the current directory and that will change based on what you define as your working directory or whatever the base image uses as a working directory. In other words, it’s kind of brittle.

  • phorq@lemmy.ml
    link
    fedilink
    Español
    arrow-up
    2
    ·
    edit-2
    8 months ago

    If the script is working like that it implies that your working_dir is / inside the container, hence why your python script can write to ./data instead needing to say of /data with the absolute forward slash. To my knowledge volumes cannot be mounted that way because the working directory inside the container is constantly changing, but you can set the initial working directory to /data. If you don’t want the python script inside the data folder/working directory but still want to be able to call it without specifying a path to the script you’ll need to copy it into a bin folder. So in summary you would have the script in bin, your working directory would be /data which would be associated with your machine’s directory you used when starting the docker-compose and the script would just use the path ./

    Edit: another option if you can’t change the starting working directory is simply to cd first: cd /data && yourscript

  • SolidGrue@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    8 months ago

    You’ve pretty much answered it yourself in the example you gave: you can mount the host’s relative path ./ to an absolute path /data in the compose file, and the container will mount the $CWD at launch as /data.

    I think most bind mounts are default read-only, which is why your write is failing. Try adding ,rw to the end of the list entry in volumes and see if that helps.

    edit: another poster got it with working_dir which also is more right

    Using relative paths is bad practice, by the way. It’s fine for development and testing, but in production you would want always to use absolute paths. Think of it as a bad habit that leaves surprises for yourself and othere down the road when moving or replicating projects. If you want it to be more dynamic, consider using compose vars and environment variables

    Another thing you might want to consider is not mounting the project root as a RW filesystem in your containers, since this allows the container to modify its own compose file. That’s rarely something you’d want to do. Better to make a subdirectory for each container in the project folder, and mount those into the appropriate contains