Docker-composeでdocker-machineを使用しようとしています。ファイルdocker-compose.ymlの定義は次のとおりです。
web:
build: .
command: ./run_web.sh
volumes:
- .:/app
ports:
- "8000:8000"
links:
- db:db
- rabbitmq:rabbit
- redis:redis
docker-compose up -d
を実行すると、コマンドを実行しようとしてエラーが発生するまですべてうまくいきます。
コンテナb58e2dfa503b696417c1c3f49e2714086d4e9999bd71915a53502cb6ef43936dを開始できません:[8]システムエラー:exec: "./run_web.sh":stat ./run_web.sh:no such file or directory
ローカルボリュームはリモートマシンにマウントされません。 webappsのコードでローカルボリュームをマウントするための推奨戦略は何ですか?
また、この問題に遭遇し、docker-machineを使用するとローカルボリュームがマウントされていないようです。ハックソリューションは
docker-machineインスタンスの現在の作業ディレクトリを取得しますdocker-machine ssh <name> pwd
rsync
のようなコマンドラインツールを使用して、フォルダーをリモートシステムにコピーします。
rsync -avzhe ssh --progress <name_of_folder> username@remote_ip:<result _of_pwd_from_1>.
デフォルトのpwdは/ rootであるため、上記のコマンドはrsync -avzhe ssh --progress <name_of_folder> username@remote_ip:/root
になります
注意:リモートシステムのパスワードを入力する必要があります。 sshを使用してリモートシステムにすばやく作成し、パスワードを作成できます。
docker-compose.yml
ファイルのボリュームマウントポイントを.:/app
から/root/<name_of_folder>:/app
に変更します
docker-compose up -d
を実行します
注:ローカルで変更が行われた場合、rsync
を再実行して変更をリモートシステムにプッシュすることを忘れないでください。
完全ではありませんが、機能します。問題は進行中です https://github.com/docker/machine/issues/179
これを解決しようとする他のプロジェクトには、 docker-rsync が含まれます
Docker-machineはユーザーディレクトリを自動マウントします...しかし、時にはそれだけでは十分ではありません。
Docker 1.6については知りませんが、1.8では、docker-machineに追加のマウントを追加できますできます
CLI:(マシンが停止している場合のみ機能します)
VBoxManage sharedfolder add <machine name/id> --name <mount_name> --hostpath <Host_dir> --automount
したがって、Windowsの例は次のようになります
/c/Program\ Files/Oracle/VirtualBox/VBoxManage.exe sharedfolder add default --name e --hostpath 'e:\' --automount
GUI:(マシンを停止する必要はありません)
<machine name>
を右クリック(デフォルト)<Host dir>
(e :)<mount name>
(e)boot2dockerで手動でマウント:
docker-machine ip default
などでdockerにssh/PuTTYを使用するなど、さまざまな方法があります。Sudo mkdir -p <local_dir>
Sudo mount -t vboxsf -o defaults,uid=`id -u docker`,gid=`id -g docker` <mount_name> <local_dir>
しかし、これはマシンを再起動してからマウントが失われるまで有効です...
boot2dockerへの自動マウントの追加:
マシンにログイン中
/mnt/sda1/var/lib/boot2docker/bootlocal.sh
、sda1は異なる場合があります...追加する
mkdir -p <local_dir>
mount -t vboxsf -o defaults,uid=`id -u docker`,gid=`id -g docker` <mount_name> <local_dir>
これらの変更により、新しいマウントポイントが必要になります。これは、ブート時に呼び出され、永続的であることがわかっている数少ないファイルの1つです。より良い解決策が見つかるまで、これは機能するはずです。
古い方法:推奨しない、ただし代替として残しました
/mnt/sda1/var/lib/boot2docker/profile
、sda1は異なる場合があります...追加する
add_mount() {
if ! grep -q "try_mount_share $1 $2" /etc/rc.d/automount-shares ; then
echo "try_mount_share $1 $2" >> /etc/rc.d/automount-shares
fi
}
add_mount <local dir> <mount name>
最後の手段として、もう少し面倒な代替手段を取ることができ、ブートイメージを変更するだけです。
git -c core.autocrlf=false clone https://github.com/boot2docker/boot2docker.git
cd boot2docker
git -c core.autocrlf=false checkout v1.8.1
#または適切なバージョンrootfs/etc/rc.d/automount-shares
を編集最後にfiの直前にtry_mount_share <local_dir> <mount_name>
行を追加します。例えば
try_mount_share /e e
/ binなど、osが必要とするものに設定しないようにしてください。
docker build -t boot2docker .
#最初に約1時間かかります:(docker run --rm boot2docker > boot2docker.iso
これは機能しますが、長くて複雑です
dockerバージョン1.8.1、docker-machineバージョン0.4.0
現時点では、マシンにボリュームをマウントする方法が実際にはわかりません。そのため、今のところ、必要なファイルを何らかの方法でマシンにコピーまたは同期する方法です。
Docker-machineのgithubリポジトリでこの問題を解決する方法について 会話 があります。誰かが プルリクエスト 実装 scp をdocker-machineで作成し、すでにmasterでマージされているため、次のリリースでそれが含まれる可能性が非常に高いです。
まだリリースされていないため、コードをgithubでホストしている場合は、アプリを実行する前にリポジトリを複製することをお勧めします
web:
build: .
command: git clone https://github.com/my/repo.git; ./repo/run_web.sh
volumes:
- .:/app
ports:
- "8000:8000"
links:
- db:db
- rabbitmq:rabbit
- redis:redis
更新:さらに見ると、この機能は latest binaries で既に利用可能であることがわかりました。それらを取得すると、次のようなコマンドを実行してローカルプロジェクトをコピーできます。
docker-machine scp -r . dev:/home/docker/project
これが一般的な形式であること:
docker-machine scp [machine:][path] [machine:][path]
そのため、マシン間、マシン間でファイルをコピーできます。
乾杯!1
Docker-machineでrsyncオプションを選択した場合、次のようにdocker-machine ssh <machinename>
コマンドと組み合わせることができます。
rsync -rvz --rsh='docker-machine ssh <machinename>' --progress <local_directory_to_sync_to> :<Host_directory_to_sync_to>
このコマンド形式のrsyncを使用して、Host
を空白のままにします。
rsync [OPTION]... SRC [SRC]... [USER@]Host:DEST
2017年10月以降、この操作を行うdocker-machineの新しいコマンドがありますが、実行する前にディレクトリに何もないことを確認してください。
docker-machine mount <machine-name>:<guest-path> <Host-path>
詳細については、ドキュメントを確認してください: https://docs.docker.com/machine/reference/mount/
最後に、Windows Docker Toolboxをv1.12.5にアップグレードし、Oracle VM VirtualBox
managerに共有フォルダーを追加してパス変換を無効にすることで、ボリュームを機能させる方法を見つけました。 Windows 10以降をお持ちの場合は、新しいDocker for Windowsを使用することをお勧めします。
最初のアップグレードの痛み:
Redisデータベースの例:redis: image: redis:Alpine container_name: redis ports: - "6379" volumes: - "/var/db/redis:/data:rw"
Dockerクイックスタートターミナルで....
docker-machine stop default
を実行します-VMが確実に格納されるようにしますOracle VM VirtualBox Managerで...
default
VMに共有フォルダーを追加しましたD:\Projects\MyProject\db
=> /var/db
docker-compose.yml
...で.
"/var/db/redis:/data:rw"
Dockerクイックスタートターミナルで....
COMPOSE_CONVERT_WINDOWS_PATHS=0
を設定(ツールボックスバージョン> = 1.9.0の場合)docker-machine start default
を実行してVMを再起動します。cd D:\Projects\MyProject\
docker-compose up
が動作するはずです。D:\Projects\MyProject\db\redis\dump.rdb
にredisデータベースを作成します
なぜ相対ホストパスを避けるのですか?
IWindows Toolboxの相対的なホストパスは、無効な '\'文字を導入する可能性があるため回避しました。 docker-compose.yml
に関連するパスを使用するほどナイスではありませんが、少なくとも私の仲間の開発者は、プロジェクトフォルダーが他の場所にある場合でも、docker-compose.yml
ファイルをハッキングせずに簡単に実行できます(SCMにとっては悪い)。
元の問題
参考までに...これは、以前のバージョンでうまく機能していたニースのクリーンな相対パスを使用したときに得られた元のエラーです。私のボリュームマッピングは以前は"./db/redis:/data:rw"
でした
ERROR: for redis Cannot create container for service redis: Invalid bind mount spec "D:\\Projects\\MyProject\\db\\redis:/data:rw": Invalid volume specification: 'D:\Projects\MyProject\db\redis:/data
これは2つの理由で壊れます。
D:
ドライブにアクセスできません\
文字を含めることはできませんdocker-compose
はそれらを追加し、それをあなたのせいにします!!COMPOSE_CONVERT_WINDOWS_PATHS=0
を使用して、このナンセンスを停止します。VirtualBoxを再度アンインストールして共有フォルダーをリセットする必要がある場合があるため、追加のVM共有フォルダーマッピングをdocker-compose.yml
ファイルに文書化することをお勧めします。
Windows 10で18.03.1-ce-win65(17513)を使用していることに触れただけで、以前にドライブを共有して資格情報をキャッシュしていた場合、パスワードを変更するとドッカーがコンテナー内にブランクとしてマウントされたボリューム。
実際に何が起こっているのかは、古いキャッシュされた資格情報で共有にアクセスできなくなっていることを示すものではありません。このシナリオの解決策は、UI([設定]-> [共有ドライブ])を使用して資格情報をリセットするか、ドライブの共有を無効にしてから新しいパスワードを入力することです。
これらの状況でdocker-composeがエラーを出した場合に役立ちます。
run_web.sh
ファイルはdocker-compose.yml
ファイルと同じディレクトリにあると仮定します。その場合、コマンドはcommand: /app/run_web.sh
になります。
Dockerfile
(開示していない)がrun_web.sh
ファイルをDockerイメージに入れることを処理しない限り。
ここに投稿を要約した後、Virtualboxの再起動時に追加のホストマウントポイントと自動マウントを作成するための更新されたスクリプトを添付しました。作業環境の概要は次のとおりです。-Windows 7-docker-machine.exeバージョン0.7.0-VirtualBox 5.0.22
#!env bash
: ${NAME:=default}
: ${SHARE:=c/Proj}
: ${MOUNT:=/c/Proj}
: ${VBOXMGR:=C:\Program Files\Oracle\VirtualBox\VBoxManage.exe}
SCRIPT=/mnt/sda1/var/lib/boot2docker/bootlocal.sh
## set -x
docker-machine stop $NAME
"$VBOXMGR" sharedfolder add $NAME --name c/Proj --hostpath 'c:\' --automount 2>/dev/null || :
docker-machine start $NAME
docker-machine env $NAME
docker-machine ssh $NAME 'echo "mkdir -p $MOUNT" | Sudo tee $SCRIPT'
docker-machine ssh $NAME 'echo "Sudo mount -t vboxsf -o rw,user $SHARE $MOUNT" | Sudo tee -a $SCRIPT'
docker-machine ssh $NAME 'Sudo chmod +x /mnt/sda1/var/lib/boot2docker/bootlocal.sh'
docker-machine ssh $NAME 'Sudo /mnt/sda1/var/lib/boot2docker/bootlocal.sh'
#docker-machine ssh $NAME 'ls $MOUNT'
ローカルマシンのvirtualboxドライブでdocker-machine 0.12.2を使用しています。ローカルファイルにアクセスできるディレクトリ/hosthome/$(user name)
があることがわかりました。
他のすべての回答は当時は良かったが、現在(Docker Toolbox v18.09.3)はすべてそのまま使用できます。 VirtualBox VMに共有フォルダーを追加するだけです。
Docker Toolboxは自動的にC:\Users
を共有フォルダー/c/Users
として仮想Linuxマシンの下に追加します(Virtual Box共有フォルダー機能を使用)。したがって、docker-compose.yml
ファイルがこのパスの下のどこかにあり、ホストマシンのディレクトリをこのパスの下でのみマウントする場合、すべてが動作するはずですボックス。
例えば:
C:\Users\username\my-project\docker-compose.yml
:
...
volumes:
- .:/app
...
.
パスは自動的に絶対パスC:\Users\username\my-project
に変換され、その後/c/Users/username/my-project
に変換されます。そして、これはまさにこのパスがLinux仮想マシンの観点から見られる方法です(確認できます:docker-machine ssh
、次にls /c/Users/username/my-project
)。したがって、最終的なマウントは/c/Users/username/my-project:/app
になります。
すべてが透過的に機能します。
ただし、ホストマウントパスがC:\Users
パスの下にない場合、これは機能しません。たとえば、docker-compose.yml
の下に同じD:\dev\my-project
を配置した場合。
ただし、これは簡単に修正できます。
docker-machine stop
)。Virtual Box GUIを開き、default
という名前の仮想マシンの設定を開き、Shared Folders
セクションを開いて、新しい共有フォルダーを追加します。
D:\dev
d/dev
OK
を2回押して、Virtual Box GUIを閉じます。
docker-machine start
)。それで全部です。 D:\dev
の下のホストマシンのすべてのパスは、docker-compose.yml
マウントで動作するはずです。