简单地说为什么开发人员应该关心docker？
PS：这篇文章的父级问题是将docker引入开发团队的含义
#1 楼
可能不是您要找的答案，而是一个答案:)了解docker及其部署方法实际上可以通过使其成为项目或团队开发的一部分而包含在业务需求中就像代码语言，版本控制系统，编译器，测试基础结构等环境一样，要在该团队中工作或在该项目中工作，一个人需要了解并使用所有这些，不能“自备” （在大多数情况下）。
如果“开发人员”实际上是整个开发团队的大部分甚至全部，情况会变得有些复杂。在没有任何开发人员实际支持的情况下在开发环境中推送工具将非常困难。请花时间先从团队的技术领导者那里创建这样的支持者。
侧面说明：团队中的每个开发人员不一定都必须成为Docker专家。用预先准备好的简单命令打包的预先建立的使用方法通常使开发人员可以使用基于docker的解决方案，而实际上并不了解其内部工作原理，这在相当大的程度上是可以接受的，尤其是在大型团队中。就像能够在不了解最终产品构建方式的所有细节的情况下提供代码一样。
#2 楼
我给你我的看法。开发人员应该关心Docker，因为还有其他开发人员愿意使用Docker，并且已经在其中积累了专业知识。他们愿意担任开发人员，同时担当DevOps工程师的角色。因此，DevOps的Ops部分就是他们现在正在建立的专业知识。如今，您将找到越来越多的人，他们可以开发，协调，自动化测试，自动化作业以及构建工具来监控并将完整的软件包单手投入生产。这些人正在开发人员社区中推广docker和其他工具。
此外，市场的潮流是虚拟化，自动扩展，自动化，机器学习以及适用于所有这些的docker。使用docker已经变得非常必要。企业愿意为承担所有这些职责的一个人支付2倍的费用，并且在对此类人有需求时，也将开始供应。这是从雇员-雇主的角度来看的。 DevOps工程师和开发人员在这里拥有绝大部分的技能，因此有时会进行职责协商。
开发人员可以做的最起码的工作就是共享他的二进制文件，但是他需要了解二进制文件将用于在Docker容器中运行，并且他需要了解docker的工作方式。对于kubes，warm，mesos等，开发人员甚至可能不在乎所使用的内容，但是开发人员应该非常了解docker的基础知识，并且从一开始就应该有一种心态来构建松散耦合的应用程序，以便重新使用微服务。如果应用程序是按照这种思维方式构建的（这需要docker的基础知识），那么DevOps工程师可以从那里开始进行应用程序的扩展，协调，测试，部署和监视。
而且，在大多数情况下，没有一种尺码适合所有事物。开发人员不清楚如何构建Docker友好的应用程序，而DevOps工程师则完全不了解应用程序构建过程的内部。因此，在大多数情况下，组织倾向于将这两项任务交给同一个人以加快处理速度。如果存在其他问题，则需要DevOps团队到开发团队之间的持续反馈机制，以使应用程序更具有未来派性，并为docker / cloud / scaling提供就绪。
#3 楼
这与Docker或任何其他容器化技术无关。您正在构建自己的部署，使其包含内部所需的一切，而最终用户只需要运行时即可。这些解决方案类似于Java中的胖JAR，理论上您需要这些一切只是预安装了运行时（JRE）以及所有的Just Works™。 ）编排工具，这使您比“传统”部署具有一些优势。
牛，而不是宠物。关键在于，当服务器死机时，您应该耸耸肩等待新的出现。您将它们视为牛，有数十，数百，数千只它们在运行，当它们掉下来时，您或您的客户都不应该意识到这一点。群集中的应用程序（pods / jobs等），并且当发现其中一台服务器停止响应（关闭）时，它将自动将在该服务器上运行的所有应用程序移动到其他位置。资源利用
借助业务流程，您可以在一台服务器上运行多个应用程序，业务流程将为您跟踪资源。
不可变的基础架构
由于业务流程管理器中的自动故障转移处理，您可以按需在云中运行自定义映像。当您需要更新时，只需构建新映像，将启动配置设置为立即使用该映像，然后滚动即可。一切都会为您处理：
使用新配置创建新服务器。
杀死一台正在运行的服务器。
您的协调器会将所有内容移至其他计算机（包括新计算机）。
如果还有旧服务器，请转到1。
简单操作
资源不足？将新计算机添加到群集。
需要更多应用程序实例吗？增加数量并继续。
监控？做完了
日志管理？做完了
秘密？猜猜是什么。
TL; DR整个问题不是关于Docker而是关于编排。 Docker只是tarball / fat JAR的扩展版本，需要进行适当的编排。
评论
现在，这就是我要问的，这就是整个问题所在。开发人员是否应该关心更好的资源利用，不可变的基础结构和更简单的操作？……我认为他们应该专注于交付业务需求和代码优化，以更好地利用资源。如果它是糟糕的/平均的书面代码，即使docker也无助于更好的利用。让我们接受一个事实，即业务需求使开发人员可以更快地交付内容。通过这样做，他们没有时间优化代码。为什么要对他们增加码头工人的责任？
– Abhay Pai
17年8月22日在4:39
事实是，从测试到实现，再到部署，再到整个堆栈的概述，您可以了解软件的使用方式，边缘情况以及崩溃的原因。它会降低您编写的LOC的速度，但会大大提高其质量。从长远来看节省时间
–莫里茨
18年1月9日在18:18
#4 楼
例如，以下是2014年发表的一篇博客文章中的一些论点，其标题与您的答案非常匹配： />在提交最终的经过测试的代码然后使其在最终的生产服务器上运行之间，仍然存在着巨大的痛苦点。 Docker大大简化了最后一步，无论您运行的是哪种Linux版本，Docker都使保留传统OS变得微不足道。
thenewstack.io/为什么要关心码头工人/
评论
我同意注入新技术。但是也有一些问题。就像将docker用于数据库一样（percona.com/blog/2016/11/16/is-docker-for-your-database）。他们目前还不稳定，将来可能会稳定。让我们期盼最好的结果。无论如何，我们可以通过使用CI / CD来实现将经过测试的代码推送到生产环境中。那为什么要码头工人？开发人员不在乎我们在运行什么操作系统。他们为什么还要首先去学习docker？使生活更轻松？
– Abhay Pai
17年8月14日在6:08
首先，我只考虑以下“ MVP”场景：imagemagick说，开发人员尝试了一些新的环境/基础设施组件配置/工具。如果没有Docker，这些信息可能会丢失或遗忘，或者需要与许多其他细微的事物进行交流。共享Dockerfile是机器可验证的工作设置，甚至可以用来将设置手动构建为不依赖Docker的基础架构，而不仅仅是文档。当然，您也可以去参加Puppet。关于Docker的一件好事是恕我直言，它如何允许独立的场景。
– Peter Muryshkin
17年8月14日在6:22
同意但是问题是在编排过程中出现的。开发人员需要在docker编排方面具有专业知识，以便遵守最佳实践并交付业务需求。考虑您的开发人员需要imagemagick作为服务的方案。现在，在构建dockerfile时，他/她可以完全控制自己可以安装在docker映像中的软件包。如果他们将sshd安装到ssh而不是使用docker日志，该怎么办？如果他们安装与业务逻辑无关但会损害安全性的工具怎么办？开发人员需要Docker专业知识吗？
– Abhay Pai
17年8月14日在12:19
嗯，但是如果他们实现基于套接字的后门呢？我认为docker不能取代企业防火墙
– Peter Muryshkin
17年8月14日在12:50
真正。但这在任何情况下都是开发人员的恶意意图。不管是码头工人还是没有码头工人。但是，当将docker引入开发人员时，他们可能会因为缺乏相应的知识而引起不幸。当可能会导致不幸和麻烦的事情发生时，为什么他们甚至还要费心地学习docker（考虑协调器也会增加复杂性）？请不要介意我的问题。甚至我也喜欢docker。但是我试图理解开发人员的观点。我过去三年一直是开发人员，现在是DevOps工程师。
– Abhay Pai
17年8月14日在15:19
#5 楼
如果您在docker容器中运行生产，则至关重要的是，这些容器是由在其上运行应用程序的开发人员来制造的。还有谁可以更好地了解需要哪些外部依赖项，依此类推。 ..？
在CD期间，流水线也可能在任何步骤中失败，尤其是在docker映像构建步骤中，有时是缺少文件或需要lib的情况。
在工作中，我们向docker介绍了所有开发人员，向他们介绍了构建dockerfile以便服务于他们的应用程序的基础知识，我们还简化了管道，因此一个人只能添加一个名称和一个dockerfile，其应用程序将自动在下一个构建无论技术如何运行，都可以进行推送。
在devOps团队指导开发人员选择发行版之后，Docker quickstart确实是一个很棒的介绍（很多人都不了解像
alpine）。 我们的工作是为他们提供易于使用的工具，其余的工作由他们完成，以便在出现问题时可以对其进行修复。 Docker确实是开发过程的一部分，devOps团队为他们提供了满足我们需求的Docker映像，这些映像非常容易，因此只需几分钟即可创建新应用并在没有帮助的情况下进行部署。
评论
因此，根据开发人员的说法，仅在项目需要外部依赖项时才应使用docker在项目中的使用。我认为docker已经成为我们开发过程的一部分，因为我们已经在开发人员身上实施了它，或者因为我们认为它很酷。在编排过程中也会出现问题。他们是否需要学习编组，例如群，kubernetes或mesos？所有这些业务流程的实现都是不同的。如果业务流程由于执行不当而崩溃，该怎么办？谁应该受到指责？ PS：别介意我的问题。我只是在扮演devli的拥护者。我也爱docker :)
– Abhay Pai
17年8月14日在12:28
#6 楼
Docker得到了很多新闻和博客提及，这使开发人员对使用它产生了兴趣。对于某些人来说，有兴趣使用新技术或了解事物的工作方式。对于其他人，则希望在其简历中添加关键字。无论哪种方式，开发人员对事情如何工作以及如何进行部署的了解越多，以后就不会感到惊讶。从我所看到的情况来看，对此已经有相当大的兴趣，因此进一步鼓励它应该不难。#7 楼
好吧，如果您曾经使用过VM进行测试，则可能需要尝试使用容器，而docker实际上是一个很棒的测试工具，它比LXC更容易使用:)评论
同意我不反对使用docker或它的各种编排工具。我也喜欢他们。我想了解的很简单。谁拥有应用程序的容器化。开发人员？还是DevOps？或两者 ？如果两者都应贡献多少？当事情由于docker或docker Orchestration而失败时，应该由谁负责？代码效率vs帮助开发人员简化生活。我的问题倾向于个人的角色，而不是技术本身。
– Abhay Pai
17年8月22日在4:47
评论
此外，您可以基于所需的任何技术，从而为您提供了更少的限制，也减少了系统管理员支持所有不同技术的麻烦。并且由于“开发人员”决定了技术，因此应该由他来配置docker环境。
– DarkMukke
17年8月16日在11:11
@DarkMukke“开发人员”并不总是决定技术...在大型开发人员团队中，情况恰恰相反-“开发人员”仅使用团队使用的任何技术。如果异常不会干扰或负面影响团队的活动，则可以容忍异常。
–丹·科尼莱斯库（Dan Cornilescu）
17年8月19日在17:28
我部分同意，但我已经看到大型（200多家）开发公司以我所描述的方式与Docker合作。我认为这不仅取决于开发团队的个人选择，还取决于他们上方的管理人员的个人选择。如果有不错的devop，那么开发人员所需的docker数量通常很少。
– DarkMukke
17年8月20日在0:11