Dockerfile有十多个指令。本节我们来系统讲解这些指令,指令的一般格式为指令名称 参数
。
ADD指令用于复制文件,格式为:
从src目录复制文件到容器的dest。其中src可以是Dockerfile所在目录的相对路径,也可以是一个URL,还可以是一个压缩包
② 如果src是一个URL,同时dest不以斜杠结尾,dest将会被视为文件,src对应内容文件将会被下载到dest。
③ 如果src是一个URL,同时dest以斜杠结尾,dest将被视为目录,src对应内容将会被下载到dest目录。
④ 如果src是一个目录,那么整个目录下的内容将会被拷贝,包括文件系统元数据。
⑤ 如果文件是可识别的压缩包格式,则docker会自动解压。
注:该指令已过时,建议使用如下形式:
该指令用于设置启动镜像时的用户或者UID,写在该指令后的RUN、CMD以及ENTRYPOINT指令都将使用该用户执行命令。
该指令使容器中的一个目录具有持久化存储的功能,该目录可被容器本身使用,也可共享给其他容器。当容器中的应用有持久化数据的需求时可以在Dockerfile中使用该指令。格式为:
当该Dockerfile被构建成镜像后,/tmp目录中的数据即使容器关闭也依然存在。如果另一个容器也有持久化的需求,并且想使用以上容器/tmp目录中的内容,则可使用如下命令启动容器:
切换目录指令,类似于cd命令,写在该指令后的RUN
,CMD
以及ENTRYPOINT
指令都将该目录作为当前目录,并执行相应的命令。
Dockerfile还有一些其他的指令,例如STOPSINGAL、HEALTHCHECK、SHELL等。由于并不是很常用,本书不作赘述。有兴趣的读者可前往 扩展阅读。
}
简介 这篇文章主要介绍了在Gitlab中传递--build-arg或在两步Dockerfile中使用环境变量(示例代码)以及相关的经验技巧,文章约7195字,浏览量216,点赞数6,值得推荐!
我的最小测试项目布局如下所示。
访问正在运行的容器具有预期的结果。检查文件系统进一步显示拾取传递的构建参数并相应地写入文件。
但是,当我将此代码推送到Gitlab时,部署的nginx如下所示:
我想要完成的是通过设置 - > CI / CD下的Gitlab UI定义的环境变量被拾取并在Dockerfile中定义的构建阶段中使用。由于我们对Auto Dev感到满意,我们还没有创建和检查.gitlab-ci.yml文件。
稍微修补一下后,我现在可以访问环境变量,但是我失去了Auto DevOps的便利性。
将存储库推送到Gitlab后,管道成功,我可以下载工件,解压缩,通过docker load -i image/my_image.tar
加载并运行它。当然,页面加载了Gitlab CI / CD UI中定义的变量。但是,现在我已经失去了部署过程的所有其他步骤(这是我不想首先编写.gitlab-ci.yml的主要原因)。
使用我在找到的Auto DevOps模板,我进行了以下更改:
现在,我陷入了审查阶段。
在更新#2之后,这些是我为使其工作所做的更改。
从我找到的模板中使用更多,并重写了deploy / build.sh:
}