我应该使用Dockerfiles还是图像提交? [英] Should I use Dockerfiles or image commits?

查看:105
本文介绍了我应该使用Dockerfiles还是图像提交?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我对这两个选项感到有些困惑。他们似乎是相关的。但是,它们并不真正兼容。



例如,似乎使用Dockerfiles意味着您不应该真正提交图像,因为您应该只是跟踪在git中的Dockerfile并对其进行更改。那么关于什么是权威性就没有歧义。



然而,图像提交似乎非常好。它非常好,您可以直接修改容器,并标记更改以创建另一个图像。我明白你甚至可以从图像提交历史中获取像文件系统差异的东西。真棒。但是你不应该使用Dockerfiles。否则,如果你做了一个图像提交,你将不得不回到你的Docker文件,并进行一些更改代表你做了什么。



所以我被撕毁了。我喜欢图像提交的想法:您不必在Dockerfile中表示您的图像状态 - 您可以直接跟踪它。但是我很放心放弃某种清单文件,这样可以快速了解图像中的内容。在同一个软件包中看到两个不兼容的功能也是令人不安的。



有没有人有这个想法?使用图像提交是否被认为是不好的做法?或者我应该放弃我的附件来显示我的Puppet日子里的文件?我应该怎么做?



更新



是一个基于意见的问题:客观和主观之间存在一系列问题。虽然这个问题确实有主观的方面,但我认为这主要是一个客观的问题。此外,我相信有关这个话题的启发性讨论将会是有益的。



最后,我希望看到这篇文章的人将会更好地了解Dockerfiles和图像提交相互关联。

解决方案

Dockerfiles是用于创建图像的工具。



运行 docker build的结果。是一个带有提交的图像,所以不可能使用一个Docker文件,用于创建提交。问题是,每次有任何变化时,您应该手动更新图像,从而使自己成为黄金图像的诅咒?



金色形象的诅咒是一个可怕的诅咒,人们必须继续生活在一个穿越安全漏洞的基础图像上运行他们的软件,因为创造者很久以前被古代人吞噬了(或转移到一个新工作),没有人知道他们获得了那个形象的imagemagic的版本。并且是连接到由三年前雇用的老板的儿子的顾问提供的c ++模块的唯一的东西,无论如何,这并不重要,因为即使你想出了哪些imagemagic来自于libstdc ++使用的版本JNI在支持工具中打电话,实习生长时间的头发只存在于ubuntu的不受支持的版本。


I'm a little bit confused about these two options. They appear to be related. However, they're not really compatible.

For example, it seems that using Dockerfiles means that you shouldn't really be committing to images, because you should really just track the Dockerfile in git and make changes to that. Then there's no ambiguity about what is authoritative.

However, images commits seem really nice. It's so great that you could just modify a container directly and tag the changes to create another image. I understand that you can even get something like a filesystem diff from an image commit history. Awesome. But then you shouldn't use Dockerfiles. Otherwise, if you made an image commit, you'd have to go back to your Dockerfile and make some change which represents what you did.

So I'm torn. I love the idea of image commits: that you don't have to represent your image state in a Dockerfile -- you can just track it directly. But I'm uneasy about giving up the idea of some kind of manifest file which gives you a quick overview of what's in an image. It's also disconcerting to see two features in the same software package which seem to be incompatible.

Does anyone have any thoughts on this? Is it considered bad practice to use image commits? Or should I just let go of my attachment to manifest files from my Puppet days? What should I do?

Update:

To all those who think this is an opinion-based question: There is a spectrum of questions that vary between objective and subjective. Though this question does have aspects that are subjective, I believe it is mostly an objective question. Furthermore, I believe an enlightened discussion on this topic will be informative.

In the end, I hope that anyone reading this post will come away with a better understanding of how Dockerfiles and image commits relate to each other.

解决方案

Dockerfiles are a tool that is used to create images.

The result of running docker build . is an image with a commit so it's not possible to use a Dockerfile with out creating a commit. The question is should you update the image by hand each time anything changes and thus doom yourself to the curse of the golden image?

The curse of the golden image is a terrible curse cast upon people who must continue living with a buggy security hole ridden base image to run their software on because the person who created it was long ago devoured by the ancient ones (or moved on to a new job) and nobody knows where they got the version of imagemagic that went into that image. and is the only thing that will link against the c++ module that was provided by that consultant the boss's son hired three years ago, and anyway it doesn't matter because even if you figured out where imagemagic came from the version of libstdc++ used by the JNI calls in the support tool that intern with the long hair created only exists in an unsupported version of ubuntu anyway.

这篇关于我应该使用Dockerfiles还是图像提交?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆