在Dockerfiles中延续线的延长
我最近和Docker一起工作来托pipeRStudio-server实例。 有一些需要安装的软件包，在Dockerfile中这样做的一个方法就是这样（显然有更多的行）：
RUN Rscript -e "install.packages('beanplot')" RUN Rscript -e "install.packages('beeswarm')" RUN Rscript -e "install.packages('boot')" RUN Rscript -e "install.packages('caTools')" 我看到很多这样做的例子：
RUN Rscript -e "install.packages(c('beanplot','beeswarm','boot','caTools'))
另外，我经常看到各种可执行文件链像这样链接在一起：
RUN yum -y update \ && yum -y groupinstall 'Development Tools' \ && yum -y install epel-release \ vim \ initscripts \ libpng-devel \ mesa-libGL \ mesa-libGL-devel \ mesa-libGLU \ mesa-libGLU-devel \ ypbind \ rpcbind \ authconfig \ && yum -y install R \ && mkdir /rhome
而不是把&&行作为单独的RUN行。
我曾经认为好处是减lessdocker图像的大小，但是当我testing一个大的例子时，任何一种方法都会导致相同的大小。
链接命令的优势是什么，而不是每行有单独的RUN命令？
每个RUN命令都会为图像添加一个新图层，并且允许的图层数量有上限（大约在255左右）。 性能方面的限制是强制执行的。
每次在容器中运行的应用程序需要访问文件时，引擎都会从上到下search所有这些层中的文件，直到find它为止。 如果应用程序尝试更改不在最顶层的文件，则引擎首先在最顶层创build文件的副本，然后将应用程序的写请求处理到副本上。
最顶层是可写的。 它不存储在图像中，但它是容器的一部分。 存储在图像中的图层是只读的。
这一切都在文档中解释。 build议保留less量图层作为最佳实践 。