1、使用docker搭建开发环境 你过来看看 - SegmentFault 思否，原理讲的比较清楚。
2、docker build | Docker Documentation，关于build的官方说明。
3、docker exec的选项参数是有位置要求的。比如执行【docker exec eureka01 -i /bin/bash】是错误的，执行后会报错【OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: "-it": executable file not found in $PATH": unknown】，即认为对容器eureka01执行【-i】命令而不是后面的【/bin/bash】命令，exec的参数【-i】只有在容器之前才是正确的，即【docker exec -i eureka01 /bin/bash】。
4、docker - Modify hosts file in dockerfile - Server Fault，这篇问答解释了为什么通过Dockerfile的RUN命令修改hosts无效，是因为容器启动时会重建hosts文件，而RUN命令只是用来构建镜像的。所以必须在启动容器时执行添加hosts的操作，比如docker run或这Dockfile的CMD/ENTRYPOINT中。docker容器添加自定义hosts - 学习笔记 - CSDN博客，这篇文章的测试也证明了这个观点。Docker容器的DNS和主机名-走过岁月......，这篇文章讲解了如何修改容器的主机名。其实原理都是一样的，由于同一镜像可以启动多个容器，所以在启动容器时，文件【/etc/hostname】和【/etc/hosts】会被docker重新写入，其中主机名是随机值，从而保持容器的唯一性。
5、在pom的【properties】中添加属性【dockerfile.contextDirectory】，即可指定要往docker服务器发送用于生成image的本地文件目录。默认是整个项目目录，如果设置为【./target】，则只向服务器发送编译目录。但同时必须要保证该目录在编译完成后要存在【dockerfile】文件，否则将无法生成镜像。
6、在使用【dockerfile-maven-plugin】时遇到坑。
docker服务器已配置好，其它项目都可以生成镜像，但有个项目就是不行，插件提示的错误是【Connection reset by peer】，把防火墙关了都不行。最后找到文章maven docker 插件集成的几个小坑 - mysgk - 博客园，才发现不是网络传输问题，而是要生成镜像的【repository】中包含大写字符，导致服务器拒收产生的网络连接错误。
使用Dockerfile Maven插件 - CokeCode - 博客园，这篇完整介绍插件的使用比较明了，但按照说明将<configuration>下的<contextDirectory>配置为【./target】，将<dockerfile>配置为【./target/classes/docker/Dockerfile】，再进行【deploy】时就会出现错误【Could not acquire image ID or digest following build】。最后也没弄明白是怎么回事，只得采取原来的方式，即通过配置<resource>将【resources/docker/Dockerfile】放到【target】下，然后在【deploy】就没问题了。
7、对【repository】的一些认识
该属性如果包含斜杠【/】，则以此符号分隔的前半部分为仓库的地址，后半部分是自定义仓库的名称，所以前半部分不能随便设置。如果前半部分的仓库地址不存在，则为默认的仓库地址，这个是可以配置的。之所以涉及这个问题，是因为通过对容器进行【commit】操作得到一个自定义镜像后，想通过【Dockerfile】的【FROM】进行引用，但总是提示不存在，但在服务器上是可以通过【docker images】查到的。所以就发现这个【FROM】操作其实是去线上仓库查找的，不论是共有仓库还是私有仓库，而不是服务器本地的镜像列表。所以为了能够在【FROM】时找到自定义镜像，当执行【commit】或【tag】时要在镜像的【repository】中指定仓库服务器地址（不论公私），再通过【pull】命令将新镜像上传到仓库服务器并能检索到，在通过【FROM】指定镜像时还必须是包含服务器地址的完整镜像名称。
8、关于docker【image】及其构建元素【layer】的【overlay2】存储
Docker存储驱动之--overlay2 - 简书，这篇文章已经讲得比较清楚，并且也都能实践成功。只是文章的最后一点需要补充说明下，就是利用【rootfs】的【diff_ids】计算出layer的真实文件夹id。除了diff_ids的第一个也即最底层layer的id能够找到对应的文件夹外，其它能够对应文件夹的真实id都需要通过【sha256sum】计算得到，并且是两两计算得到，参与计算的前一个id必须是能够对应文件夹的真实id，后一个是在【diff_ids】中的id。因此第三层layer的真实id，既不是第二个和第三个【diff_ids】的和，也不是前三个【diff_ids】的和，而是第二层layer的真实id和【diff_ids】第三个值的和。