I have created the following docker file
FROM resin/rpi-raspbian:jessie-20160831
..
RUN mkdir -p /usr/bin/asmp
COPY src /usr/bin/asmp/
VOLUME /usr/bin/asmp/data
..
The copy actions copies a directory structure like this:
data
db.sqlite3
web
...
worker
...
I than just start a container, using something like this:
docker run -p 8000:8000 asmp
When I do an inspect I see this:
"Mounts": [
{
"Name": "30ccc87580cd85108cb4948798612630640b5564f66de848a4e2f77db8148d3a",
"Source": "/var/lib/docker/volumes/30ccc87580cd85108cb4948798612630640b5564f66de848a4e2f77db8148d3a/_data",
"Destination": "/sys/fs/cgroup",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
},
{
"Name": "c4473031d209eb29d3f454be68325c6b1f33aa660185bf57e8abb91a56bb260e",
"Source": "/var/lib/docker/volumes/c4473031d209eb29d3f454be68325c6b1f33aa660185bf57e8abb91a56bb260e/_data",
"Destination": "/usr/bin/asmp/data",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
When I stop the container (by killing it) and than starting it again, it creates a new volume to a different directory. So I am wondering how to handle with this situation? Am I starting/stopping the container wrong? Or should I specify the volume differently? I do know that you can specify a target path, but can I (and should I ) specify this in the docker file? I rather specify the volume settings in the docker file, since the run command is already having a lot of parameters to redirect ports and devices..
Any thoughts?
You must specify volume destination when you run container. Read about volumes
docker run -p 8000:8000 --volume=<path_on_host>:/usr/bin/asmp/data asmp
Related
When I run this docker command like this, I get errors:
$ docker run -v $PWD:/tmp bobrik/curator --config /tmp/testconfig.yml /tmp/actions-daily.yml
Usage: curator [OPTIONS] ACTION_FILE
Error: Invalid value for "--config": Path "/tmp/testconfig.yml" does not exist.
For some reason, Docker cannot find this file path, even though that file exists in that directory and its permission is set to 775. Furthermore, when I inspect that container, I can see this Mount information:
"HostConfig": {
"Binds": [
"/cygdrive/c/myUbuntu18/rootfs/home/jdepaul/repos/curator/test/utils:/tmp"
],
and this further down:
"Mounts": [
{
"Type": "bind",
"Source": "/cygdrive/c/myUbuntu18/rootfs/home/jdepaul/repos/curator/test/utils",
"Destination": "/tmp",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
Run it on Windows, like this:
docker run -v C:\Users\ja006652\cure:/tmp bobrik/curator --config /tmp/testconfig.yml /tmp/daily-dev-action.yml --dry-run
My docker compose entry for the service is:
api:
restart: always
build: ./project/api
volumes:
- ./:/usr/src/app:ro
- ~/data:/root/data:ro # /root is the ~ in container
I run my containers using
sudo docker-compose down && sudo docker-compose up --build -d
I have 2 different machines, both with admin user. On inspection of the containers created:
sudo docker inspect project_api_1 | grep Mounts -A20
On machine 1, admin user is admin:x:1005:1001:Admin User,,,:/home/admin:/bin/zsh and admin:x:1000:1000:Debian:/home/admin:/bin/zsh on machine 2
Output on machine 1
"Mounts": [
{
"Type": "bind",
"Source": "/home/admin/project",
"Destination": "/usr/src/app",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/home/admin/data",
"Destination": "/root/data",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
}
],
Output on machine 2
"Mounts": [
{
"Type": "bind",
"Source": "/home/admin/project",
"Destination": "/usr/src/app",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/root/data",
"Destination": "/root/data",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
}
],
On machine 1, /root/data points to /home/admin/data which is the desired behavior, but on machine 2 it points to /root/data. I can fix this by using either relative path ./data (which symlinks to ~/data) or by using absolute path /home/admin/data. My docker version is same on both machines - Docker version 17.06.0-ce, build 02c1d87
I'm curious about why is this different?
On your yaml file, you're using ~/data, where ~ is the shorthand for the home directory of the user you used to run docker. From that, I guess you're running docker on machine 1 as admin, while you're running docker on machine 2 as root.
You should remember that the source directory is a directory on your host machine (not the container), so the user relevant to ~ is the user on your host machine.
Docker newbie here...
I am trying to persist docker run couch db on my local filesystem but when I run the command I don't see the db files being saved. I tried researching but I seem to be doing everything right.
jubin#jubin-VirtualBox:~$ docker run -d -p 5984:5984 -v /home/jubin/data:/usr/local/var/lib/couchdb --name couchdb klaemo/couchdb
5e0d15b933d6344d3c6a28c26e1f2f59dba796697d47ff21b2c0971837c17e54
jubin#jubin-VirtualBox:~$ curl -X PUT http://172.17.0.2:5984/db
{"ok":true}
jubin#jubin-VirtualBox:~$ ls -ltr /home/jubin/data/
total 0
on inspect it seems to be correctly configured.
"Mounts": [
{
"Type": "volume",
"Name": "ea1ab54976ef583e2ca1222b4aeea420c657d48cb0987a0467a737ee3f68df02",
"Source": "/var/lib/docker/volumes/ea1ab54976ef583e2ca1222b4aeea420c657d48cb0987a0467a737ee3f68df02/_data",
"Destination": "/opt/couchdb/data",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
},
{
"Type": "bind",
"Source": "/home/jubin/data",
"Destination": "/usr/local/var/lib/couchdb",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
According to the image documentation, the CouchDB data are stored in /opt/couchdb/data and not in /usr/local/var/lib/couchdb in the latest version of the image (2.0.0/latest).
You can also confirm this by doing docker exec -it CONTAINER_ID bash and then locating the CouchDB data inside the container.
I have created a Docker volume and mounted to a container host. Now I am trying to connect (sh to the container) to the container and access the destination, as mentioned below.
"Name": “xxxxxxxxxxxxxxxxxxxxx”,
"Source": "/var/lib/docker/volumes/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/_data",
"Destination": "/Host-data",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
When I tried to access "/Host-data", I am getting message saying "can't cd to /Host-data"
Command:
# cd /Host-data
(I have tried with "/Host-data", '/Host-data' as well)
Is this something not possible? or the steps I am following are incorrect? If this is not correct how can we copy data to this destination and view them?
I have two container one is setup as a data volume, I can go inside the data container and explore the files that are mounted from a network share with out any issues.
how ever on the second docker instance when I go to the folder with mounted volumes the folder exists but all the files and directories that should be there are not visible.
this used to work so I can only assume its due to docker 1.9 I am seeing this on a linux and mac box.
Any ideas as to the cause ? is this a bug or is there something else i can investigate ?
output of inspect.
"Volumes": {
"/mnt/shared_app_data": {},
"/srv/shared_app_data": {}
},
"Mounts": [
{
"Name": "241d3e495f312c79abbeaa9495fa3b32110e9dca8442291d248cfbc5acca5b53",
"Source": "/var/lib/docker/volumes/241d3e495f312c79abbeaa9495fa3b32110e9dca8442291d248cfbc5acca5b53/_data",
"Destination": "/mnt/shared_app_data",
"Driver": "local",
"Mode": "",
"RW": true
},
{
"Name": "061f16c066b59f31baac450d0d97043d1fcdceb4ceb746515586e95d26c91b57",
"Source": "/var/lib/docker/volumes/061f16c066b59f31baac450d0d97043d1fcdceb4ceb746515586e95d26c91b57/_data",
"Destination": "/srv/shared_app_data",
"Driver": "local",
"Mode": "",
"RW": true
}
],
the files are mounted in the docker file in this manner
RUN echo '/srv/path ipaddress/255.255.255.0(rw,no_root_squash,subtree_check,fsid=0)' >> /etc/exports
RUN echo 'ipaddress:/srv/path /srv/shared_app_data nfs defaults 0 0' >> /etc/fstab
RUN echo 'ipaddress:/srv/path /mnt/shared_app_data nfs defaults 0 0' >> /etc/fstab
and then when the container starts it runs.
service rpcbind start
mount -a
You need to be sure that the second container does mount the VOLUME declared in the first one
docker run --volumes-from first_container second_container
Make sure the first container does have the right files: see "Locating a volume"
docker inspect first_container
# more precisely
sudo ls $(docker inspect -f '{{ (index .Mounts 0).Source }}' first_container)