被抛弃，所有导入行为都会丢失，因此所谓的导入.sql 的行为在dockerfile 里实际上完全没有意义。而service xxxx start 也完全没有意义，这是启动后台服务，且不说 docker中不用后台服务，这种启动行为对文件系统根本没影响，这仅仅是让后台在构建所用的容器中运行一下，完全没有意义。最后运行容器的

体积小，但是有可能有不兼容的情况，因此一般不用alpine 的镜像，除非空间受限，体积大小很关键时才会使用。过去出现过兼容问题，但是随着 docker的使用，对alpine 的需求会越来越多，更多的兼容问题会被发现、修复，所以相信在未来这应该是个不错的选择。但是如果现在就要使用，

source : stdout remote : 172.20.0.1 host : - user : - method : get path : / code : 200 size : 612 referer : - agent : curl/7.49.1 forward : - 如果去除nginx 正常的访问日志项目外，我们就可以更清晰的看到 有哪些元数据信息可以利用了。frontend.web.nginx.serviceweb1 : image : nginx baseos : alpine containerid : f7212f7108de033045ddc22858569d0ac50921b043b97a2c8bf83b1b1ee50e34 section : frontend service : web group : alpha containername : /serviceweb1 source : stdout 可以看到，我们在logging 下所有指定的labels 都在。我们完全

这是初学 docker常常碰到的问题，此时还以虚拟机来理解 docker，认为启动 docker就是启动虚拟机，也没 有搞明白前台和后台的区别。首先，碰到这类问题应该查日志和容器主进程退出码。检查容器日志： dockerlogs < 容器id> 查看容器退出码：container id         image                           command

docker1.10 之后支持动态修改，使用 dockerupdate 命令，如： dockerupdate -m 300m

目录给容器，这就是打通了一个容器内的root 操控宿主的一个通道，使得容器内的root 可以修改所挂载的目录下的任何文件。因为当前版本的 docker中，默认情况下容器的user namespace 并未开启，所以容器内的用户和宿主用户共享uid 空间。容器内的uid 为0 的root ，就被系统视为uid 0 的宿主root ，

且需要特权去执行。但是容器不是完整系统，既没有配合的服务，也没有特权，所以自然用不了。如果你碰到这样的问题，只能再次提醒你， docker不是虚拟机。试图在容器里执行systemctl 命令的，大多都是还没有搞明白容器和虚拟机的区别，因为看到了可以有shell ，就以为这是个虚拟机，试图

间是从epoch 到当前的秒数或者毫秒数，全球都一样，这是绝对值；而时区则是由于地理位置差异、行政区划导致各地显示时间的差异。对于 docker容器而言，根本不存在宿主和容器的时间差异问题，因为他们使用的是同一个内核、同一个时钟，二者完全一样，所以根本不存在同步

dockerstop dockerservice rm 在停止容器时，都会先发sigterm 信号，等待一段时间（默认为10 秒）后，如果程序没响应，则强行sigkill 杀掉进程。这样应用进程就 有机会平滑退出，在接收到sigterm 后，可以去flush 缓存、完成文件读写、关闭数据库连接、释放文件资源、释放锁等等，然后再退出。所以试图

compose 的请求超时时限是可以配置的：export composehttptimeout 120 不过，这不是问题的解决办法，因为一般情况下不应该超时，超时的原因是因为所访问的 dockerengine 过于繁忙，而无法响应compose 的请求。应该检查具体 dockerengine 出了什么问题，是不是还在用着centos 默认的device mapper 的loop 设备，等等。