0

Question

I would like to have logs from a Python app running on a Docker container show up at spot D in the below diagram. How do I do this?

Context

I am aware that this seems to point directly at using bind mounts, but my understanding of Dockers documentation is that they strongly suggest using volumes where possible, and I would like to have this be OS agnostic (developing on macOS, planning to run on a Rasberry Pi, potentially move to AWS/some other cloud service at some point) .

Currently, I'll start my container with the following command:

$ docker run -d --mount type=volume,source=app-logs,target=/app/logs super-cool-image-name

Once it is running, I'll inspect the volume:

$ docker volume inspect app-logs
[
    {
        "CreatedAt": "2021-12-01T22:31:26Z",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/app-logs/_data",
        "Name": "app-logs",
        "Options": null,
        "Scope": "local"
    }
]

My understanding (correct me if I'm wrong) is that the above Mountpoint is at point C in the below diagram. If I then run the following (taken from this SO question):

$ docker run -it --privileged --pid=host debian nsenter -t 1 -a bash

I can go to the directory specified in the above Mountpoint and find the log file I'm looking for:

bash-5.0# cd /var/lib/docker/volumes/app-logs/_data/
bash-5.0# ls
2021-12-01_22:31:26_start.log

enter image description here

Question(s) (again)

  • How can I "map" point C to point D in order to view the log file?
  • Would doing this be bad practice, and should I just get used to going through the VM when I want to view logs?
m_squared
  • 105
  • 9
  • I would suggest using [bind mounts](https://docs.docker.com/storage/bind-mounts/) rather than volumes if you want to share files with the host system. – Nick ODell Dec 01 '21 at 23:59
  • IMHO the Docker documentation is overenthusiastic about named volumes. If you have a need to read or write the content directly from the host (inject config files, read logs) then bind mounts match your need much better. In particular, using a (supported) bind mount is a better choice than trying to read files out of Docker's private `/var/lib/docker` space. – David Maze Dec 02 '21 at 02:27
  • But usually the best practice for logs is to send them to stdout rather than a file. `docker logs` can retrieve them there, and if you use other container-management systems there are similar options. – David Maze Dec 02 '21 at 02:28
  • @DavidMaze that makes sense, thanks. What is the intended use case for for volumes then (specifically /var/lib/docker)? Is it more an area for processes within a container to reference, as opposed to one a developer would interact with much? – m_squared Dec 02 '21 at 11:43
  • Consider a database's data store; what should you mount on `/var/lib/postgresql/data`? You can't usefully use those files as an end user, but they do need to be persisted. In this context a named volume makes sense, and it can be significantly faster than a bind mount on some platforms (MacOS, WSL2). (But, it's harder to back up and restore.) – David Maze Dec 02 '21 at 11:46
  • Also consider that on other clustering systems like Kubernetes, you can't usefully access host directories at all. A Kubernetes PersistentVolumeClaim is more like a Docker named volume in that it refers to some storage in some place managed by the cluster that you can't directly access. Kubernetes has a different path to inject configuration (a ConfigMap) and again generally assumes logs go to the container's stdout. – David Maze Dec 02 '21 at 11:49

0 Answers0