我的目标是编写一个运行python脚本的docker映像,该脚本会生成很多充满随机数的csv文件,完成后将这些文件写入外部存储驱动器,然后退出容器。假设它写入了很多这样的csv文件,以致它们无法存储到内存中。
我担心的是容器遇到错误并退出(或由用户退出),然后创建了一堆必须手动清除的垃圾文件的情况。
第一个解决方案是将快速驱动器(如SSD)直接安装到容器中并对其进行写入。完成后,它将数据从此SSD传输到外部存储驱动器。这件事的坏处是,如果容器意外退出,它将在SSD上留下垃圾。
第二种解决方案是使用SSD创建一个卷,使用该卷启动一个容器,然后几乎与第一种解决方案相同。在这种情况下,如果容器意外死亡,那么体积将如何变化?它也会自动退出吗?可以将其配置为自动退出从而删除已创建的任何垃圾吗?
如果您感到好奇,最终目标是将这些容器与某种编排系统一起使用。
我担心的是容器遇到错误并退出(或由用户退出)的情况,然后容器创建了一堆必须手动清理的垃圾文件。
请注意,您可以将ENTRYPOINT Python脚本配置为自动执行必要的清除。
为您提供有关该方法的一些指导原则/示例:
trap
请注意,除了可以正常终止容器之外,您可能还需要设置restart策略,例如always或unless- stopped。例如,请参阅此codeship博客文章。
restart
always
unless- stopped
第一个解决方案是将快速驱动器(如SSD)直接安装到容器中并对其进行写入。完成后,它将数据从此SSD传输到外部存储驱动器。这件事的坏处是,如果容器意外退出,它将在SSD上留下垃圾。 第二种解决方案是使用SSD创建一个卷,使用该卷启动一个容器,然后几乎与第一种解决方案相同。在这种情况下,如果容器意外死亡,那么体积将如何变化?它也会自动退出吗?
第二种解决方案是使用SSD创建一个卷,使用该卷启动一个容器,然后几乎与第一种解决方案相同。在这种情况下,如果容器意外死亡,那么体积将如何变化?它也会自动退出吗?
尽管您提出的两个解决方案对于解决该线程的主要问题不是必需的,但我不得不提到,通常,在生产中 使用卷 而不是仅使用 bind-mount 是一种 最佳实践 。但是,当然,使用这两个方法(-v volume-name:/path或绑定安装方法-v /path:/path)中的任何一个都比根本不使用该-v选项要好,因为我记得直接在容器的可写层中写入数据意味着如果容器将丢失这些数据从图像重新创建。
-v volume-name:/path
-v /path:/path
-v