dockerfile

前言

各位想必应该记得，我们此前如果安装一个nginx的话，安装完以后，我们说过很多次了，通常不会运行在默认配置下，那因此，我们通常需要去改一改它的配置文件或者定义模块化配置文件，然后启动服务。那为什么，nginx的默认配置不符合我们的需要呢？很显然，不同的生产场景所需要用到的配置参数各个相同，因此，对方只能用一个默认的，认为适用于大多数普遍场景情形的或者适用于较小主机资源情况下的那么一个设定来启动服务，同样的逻辑，各位试想一下，如果我们从docker hub下拖下来一个nginx的镜像，去启动nginx容器的时候，请问这个镜像内的nginx容器内的配置文件一定就会符合我们的需要吗？应该说叫一定不会，基本上几乎不能完全适合我们的需要，此时我们就必须去要修改配置，那怎么改呢？

之前做法：启动容器docker exec连进容器，在内部执行vi，再reload重启

另外一种方式：假设我们把它对应的那个配置文件的路径做存储卷，从我们宿主机上加载文件，在宿主机上进行编辑，也能让它立即生效，启动容器之前先把它编辑好（容器启动之前，我们事先找一目录把配置文件准备好，然后启动容器时，把容器内的应用程序默认加载配置文件的路径与宿主机上的目录进行建立关联关系，然后去启动容器，也能加载到在宿主机上定制的配置文件）

缺点：我们在宿主上做的编辑，能不能让它立即生效呢？比如我们启动以后发现，有些参数还是需要改，改完以后依然需要重载才能生效。

还有一种方式：自制镜像

基于容器：先启动起来，交互式连入进来，做修改，改完以后，改的结果一定时保存在最上层的可写层的。这个时候我们把可写层保存在一个新镜像中，而后，我们再去创建容器时，根据我们自己所创建的镜像来使用。

缺点：做的镜像也是直接把文件直接备进镜像中的，直接写死在镜像中的就是，如果我们想在改，还是改不了，运行过程当中去修改配置的需求可能对于做运维来讲，变更不就是日常操作吗？很多时候，也有可能需要随时进行修改。那依然解决不了问题。而且这种备进镜像的设计方式，最悲惨的地方在于：一次更新，维护复杂  。环境简单可以使用。

基于dockerfile

dockerfile，相当于是一个文档，客户可以基于dockerfile生成新的容器

dockerfile仅仅是用来制作镜像的源码文件，是构建容器过程中的指令，docker能够读取dockerfile的指定进行自动构建容器，基于dockerfile制作镜像，每一个指令都会创建一个镜像层，即镜像都是多层叠加而成，因此，层越多，效率越低，创建镜像，层越少越好。因此能在一个指令完成的动作尽量通过一个指令定义。

docker镜像制作的工作逻辑

首先需要有一个制作镜像的目录，该目录下有个文件，名称必须为Dockerfile，Dockerfile有指定的格式，#号开头为注释，，指定默认用大写字母来表示，以区分指令和参数，docker build读取Dockerfile是按顺序依次Dockerfile里的配置，且第一条非注释指令必须是FROM 开头，表示基于哪个基础镜像来构建新镜像。可以根据已存在的任意镜像来制作新镜像。
————————————————
版权声明：本文为CSDN博主「紫色飞猪」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zisefeizhu/article/details/83472190