docker
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】第三个值的和。