使用shell脚本在docker容器内部挂载NFS共享

问题描述:

我有一个在Windows主机上运行的Ubuntu容器。我安装了所有的nfs客户端软件包。我可以连接到我的容器并挂载一个nfs共享。使用shell脚本在docker容器内部挂载NFS共享

这个想法是开始容器运行我的脚本让它挂载两个共享,然后运行gunicorn。

docker-compose.yml 
version: '2.1' 

services: 
    web: 
    # restart: always 
    build: . 
    expose: 
     - "5000" 
     - "80" 
    ports: 
     - "5000:80" 

    #command: gunicorn -w 4 wsgi_mount:app -b 0.0.0.0:80 --timeout 500 
    privileged: true 
    command: /bin/bash /app/entrypoint.sh 

entrypoint.sh 
------------ 
mount --verbose -t nfs -o nolock -o nfsvers=3 server:/nfs/share /app/path_to_mount1 
mount --verbose -t nfs -o nolock -o nfsvers=3 server:/nfs/share /app/path_to_mount2 
gunicorn -w 4 wsgi_mount:app -b 0.0.0.0:80 --timeout 500 

输出

does not existt point /app/path_to_mount1 
does not existt point /app/path_to_mount2 
[2017-10-04 16:29:57 +0000] [41] [INFO] Starting gunicorn 19.7.1 
[2017-10-04 16:29:57 +0000] [41] [INFO] Listening at: http://0.0.0.0:80 (41) 
[2017-10-04 16:29:57 +0000] [41] [INFO] Using worker: sync 
[2017-10-04 16:29:57 +0000] [46] [INFO] Booting worker with pid: 46 
[2017-10-04 16:29:57 +0000] [49] [INFO] Booting worker with pid: 49 
[2017-10-04 16:29:57 +0000] [50] [INFO] Booting worker with pid: 50 
[2017-10-04 16:29:57 +0000] [53] [INFO] Booting worker with pid: 53 

如果我只是有它gunicorn运行,那么附着在容器和复制过去行从脚本在每个容器固定架点它的工作原理是什么我觉得很无奈是。

如果我运行容器内的脚本,我得到了完全相同的错误

我知道的特权是正确的,我现在NFS是设置正确的,我可以手动在我的容器中工作,但如果尝试从运行完全相同的命令的容器中的bash脚本执行它“不存在点...”。顺便说一句,存在不是一个错字,它显示在控制台中。

编辑: 接受的答案完美工作,但我只是想在这里添加,如果路径存在于容器中,那么它将无法安装。如果您在docker-compose文件中定义了mount,则还需要添加更改yml文件,如果它不好,您必须首先读取该卷,否则不会重新创建该文件。

您可以使用docker deamon挂载nfs vumes。这样你就不需要在你的容器内支持nfs。我不能看到为什么要装在容器内的原因

$ docker volume create --driver local \ --opt type = nfs \ --opt o = addr = 192.168.1.1,rw \ --opt device = :/ path/to/dir \ foo

+0

是o = addr = NFS服务器和设备的IP地址=容器内的挂载点?这些共享未安装在主机上。 – Ominus

+1

o = addr是服务器设备的IP地址=是要挂载的服务器nfs的路径。显示您的语法是用于创建一个命名卷,然后您可以使用docker run -v foo:container-path中的路径装载到一个容器中。它被安装在/ var/lib/docker – herm

+0

的某个地方,谢谢这是一个真正的生活保护程序! – Ominus