为什么在使用无花果时,我的卷有时候没有安装在我的Docker容器中?

时间:2014-08-23 18:01:08

标签: docker fig

我在Docker / Fig环境中看到一个奇怪的问题。我的假设是由于容器的容量延迟,但我不确定如何确认。

我有一个包含以下内容的容器:

Dockerfile

FROM busybox
MAINTAINER Dan Rumney <email>

ADD loadsnapshot.sh /loadsnapshot.sh
RUN ["chmod", "u+x", "/loadsnapshot.sh"]

VOLUME ["/snapshot"]

ENTRYPOINT ["/loadsnapshot.sh"]

loadsnapshot.sh

#!/bin/sh

if [ "$( ls -A /snapshot)" ]; then
  echo "Loading snapshot..."
  # Do stuff
else
  echo "No snapshot to load"
fi

在我的fig.yml文件中,我有:

pdsvol:
 image: busybox
 volumes:
 - "/opt/alfresco/alf_data"
 - "/data"
 - "/mysqlbackup"
 - "/ldapbackup"
loader:
 image: "docker.myregistry.com/snapshot.loader:3.5.0"
 volumes_from: 
 - pdsvol
 volumes:
 - "/opt/snapshots/my-data/:/snapshot/"

此处的目标(可能很明显)是启动数据容器(pdsvol),然后使用我的计算机上运行的一些数据填充它。然后,pdsvol由一堆其他容器共享。

我这样做的方式是打电话

fig up pdsvol

然后

fig run --rm loader

我期待看到的是

builder@beast:/opt/docker-vm$ fig run --rm loader
Loading snapshot...
... stuff ...
Removing dockervm_loader_run_1...

,有时我也这样做。但是,有时候我会看到:

builder@beast:/opt/docker-vm$ fig run --rm loader
No snapshot to load
Removing dockervm_loader_run_1...

我可以一遍又一遍地运行fig run --rm loader,我会得到两个结果中的一个。

我的工作理论是,安装卷有一些延迟,有时它会在ENTRYPOINT脚本运行之前发生,有时也会发生。但是,如果我跑:

 docker run --rm -v /opt/snapshots/my-data/:/snapshot/ busybox ls -A /snapshot

我一直看到我期待的文件......所以这违背了这个理论。

我知道我可以在loadsnapshot.sh进行攻击并拖延,看看这是否有所帮助,但我宁愿了解正在发生的事情,而不是解决问题。

有没有人有任何想法在这里发生什么?

BTW:主机系统是Linux,所以我们在这里使用本机容器。

更新

我尝试在loadsnapshot.sh的顶部放置2s延迟,但它没有帮助。

更新2

我添加了一些日志记录到fig以转储用于创建容器的配置,并且在每个实例中(失败或否),它都是相同的:

{
 'Env': None, 
 'Hostname': None, 
 'Entrypoint': None, 
 'Dns': None, 
 'Memory': 0, 
 'OpenStdin': True, 
 'User': None, 
 'CpuShares': None, 
 'AttachStdout': True, 
 'NetworkDisabled': False, 
 'WorkingDir': None, 
 'Cmd': None, 
 'StdinOnce': True, 
 'AttachStdin': True, 
 'Volumes': {u'/snapshot/': {}}, 
 'MemorySwap': 0, 
 'VolumesFrom': None, 
 'Tty': True, 
 'AttachStderr': True, 
 'Domainname': None, 
 'Image': 'docker.myregistry.com/snapshot.loader:3.5.0', 
 'ExposedPorts': None
}

1 个答案:

答案 0 :(得分:1)

我可以用Docker 1.4.0 / Fig 1.0.1重现这个问题。

回滚到 Docker 1.3.1 为我解决了这个问题。

它仍然是一个影响许多人的开放性问题。

虽然#443已关闭,但仍有相关的未解决问题: