dockerfile 但是环境变量不起作用？

来源：蜘蛛抓取(WebSpider) 时间：2022-06-06 03:20 标签： docker安装jdk环境变量

简介  这篇文章主要介绍了在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：

开始了解Docker是健明的一篇文章，那时正在研究虚拟机（Virtual Machine），发现Docker更适合现在的需求，就从基本概念和操作命令开始学习。前期顺风顺水直到看了胡博士的文章，对其Dockerfile的内容有很多不理解，后来明白Docker并不是单一独立的存在，你想要创建的镜像集成了所需的环境、软件、数据库以及脚本等，是生信处理能力的综合性体现。

显然我知识储备不够，只能默默地回去补习。

通俗的讲，它和虚拟机的作用类似，实现与宿主机资源和系统环境的隔离。但Docker容器技术相比虚拟机具有许多优点，比如：启动速度快、占用内核资源少、轻便以及可移植性等。

在新药研发中，CFDA规定十年后对相关实验数据进行溯源性分析，依然是准确和一致的。这就需要对当初所用的环境和操作进行“打包”处理，Docker为我们提供了Dockerfile来解决自动化创建images的问题，我们可以通过编辑Dockerfile来定制镜像。按照开发和运维（DevOps）人员说法，就是一次创建或配置可以永久在不同平台运行。

Docker Containers 负责应用程序的运行，包括操作系统、用户添加的文件以及元数据

它们三者之间的关系是，通过定制化地编辑Dockerfile创建Images，Images可被下载到不同平台。

Containers是Images的一个运行实例，可以被开启和关闭。当然，还可使用docker commit命令反过来由Containers生成Images，但一般不建议这样做，主要是因为在运行中的容器中进行操作（如：安装软件或添加无关内容）会导致镜像极其臃肿。

将centos7作为基础镜像并安装一些工具

若考虑数据的储存和保密性，可使用挂载指令（VOLUME），不过需要注意的是此指令无法指定宿主机上对应的目录，而是自动生成的，因此在启动容器时选择了另一种挂载方式。

创建images并修改名称

因为在Dockerfile在当前工作目录下，所以用“ . ”代替了绝对路径。

镜像创建成功并生成了一个最终ID


"Hello,World!",其在启动容器时执行echo命令，然而奇怪的事情发生了，启动容器后确实输出了"Hello,World!"却没进入容器中，就好像没被开启。如下图：

实际上它只是开启后又立即关闭了（Created到Exited只有2秒）。这跟Docker自身机制有关，当容器内的进程全部退出时，容器也会停止运行，也就是说你得让它一直有事干，没有，就会退出。

最直接保险的方法是，Dockerfile不加入启动指令（CMD和ENTRYPOINT），这样容器启动后会有一个/bin/bash的进程在运行。有需要让脚本在容器启动时运行，则可以加-d参数让容器在后台以守护状态运行docker run -it -d IMAGES_ID

我要回帖

更多关于 docker安装jdk环境变量 的文章

 

随机推荐