开发人员为什么要关心Docker？

通常，开发人员关心满足业务需求。他/她可能具有特定堆栈或框架中的专业知识。但是他/她是否应该努力学习docker及其各种部署方法（swarm，kube，mesos等）？

简而言之，为什么开发人员应该关心docker？

PS：本文的父级问题是向开发团队介绍docker的含义

可能不是您要找的答案，但是答案仍然是:)

了解docker及其部署方法实际上可以通过使其成为项目或团队开发环境的一部分而包含在业务需求中，就像代码语言，版本控制系统，编译器，测试基础结构等一样-该团队或该项目中的一个需要了解和使用所有这些，不能“自备”（在大多数情况下）。

如果您实际上是指整个开发团队的大部分甚至全部，那么“开发人员”会使事情变得更加复杂。在没有任何开发人员实际支持的情况下在开发环境中推送工具将非常困难。首先花时间从团队的技术领导中创建这样的支持者。

附注：这可能也没有必要为每在球队每个开发者成为一个码头工人专家。用预先准备好的简单命令包装的预先建立的使用方法通常使开发人员可以使用基于docker的解决方案，而实际上并不了解其内部工作原理，这在相当大的程度上是可以接受的，尤其是在大型团队中。就像能够在不了解最终产品构建方式的所有细节的情况下提供代码一样。

我会给你我的看法。开发人员应该关心docker，因为还有其他开发人员愿意使用docker，并且已经在其中建立了专业知识。他们愿意担任开发人员，同时担当DevOps工程师的角色。因此，DevOps的Ops部分就是他们现在正在积累的专业知识。

如今，您会发现越来越多的人可以开发，协调，自动化测试，自动化作业以及构建工具来监控并将此完整软件包单枪匹马地投入生产。这些人正在开发人员社区中推广docker和其他工具。

同样，市场的潮流是虚拟化，自动扩展，自动化，机器学习以及适用于所有这些的docker。使用docker已经变得非常必要。企业愿意为承担所有这些职责的一个人支付2倍的费用，并且在对这些人有需求时，也将开始供应。从雇员雇主的角度来看。

从技术上讲，在我工作过的组织中，有单独的开发团队和DevOps团队，尽管他们在交付方面非常紧密。DevOps的工程师和开发人员在这里拥有绝大部分的技能，因此有时需要进行职责协商。

开发人员可以做的最低限度的工作就是共享他的二进制文件，但是他需要了解二进制文件将用于在Docker容器内运行，并且他需要了解docker的工作方式。对于kubes，warm，mesos等，开发人员甚至可能不在乎所使用的内容，但是开发人员应该非常了解docker的基础知识，并且从一开始就应该有一种心态来构建松散耦合的应用程序，以便重新使用微服务。如果应用程序是按照这种思维方式构建的（这需要docker的基础知识），那么DevOps工程师可以从那里开始进行扩展，编排，测试，部署和监视。

同样，在大多数情况下，没有一种尺码适合所有事物。开发人员不清楚如何构建Docker友好的应用程序，而DevOps工程师完全不知道应用程序构建过程的内部。因此，在大多数情况下，组织倾向于将这两项任务交给同一个人以加快处理速度。如果存在其他问题，则DevOps团队到开发团队之间需要一个持续的反馈机制，以使应用程序更具未来派性，并为docker / cloud / scaling做好准备。

这与Docker或其他任何容器化技术无关。

Docker，rkt等容器只是以类似于静态二进制文件的方式交付应用程序的方式。您正在构建部署，使其包含内部所需的一切，而最终用户只需要运行时即可。

这些解决方案类似于Java中的胖JAR，在理论上，您所需的一切都只是预安装的运行时（JRE），而Just Works™则应包括一切。

开发人员需要了解（他们不需要学习如何操作这种工具，而仅需要为什么）编排工具的原因是，它使您比“传统”部署具有一些优势。

牛，不是宠物

EngineYard撰写了有关此文章的出色文章。关键在于，当服务器死机时，您应该耸耸肩等待新的出现。您将它们视为牛，有数十，数百，数千只它们在奔跑，而当它们掉下来时，您或您的客户都不会意识到这一点。

编排工具通过监视群集中所有应用程序的状态（pod / jobs，等等）来实现这一目标，并且当发现其中一台服务器停止响应（关闭）时，它将自动将在该服务器上运行的所有应用程序移动到其他位置。

更好地利用资源

借助业务流程，您可以在一台服务器上运行多个应用程序，业务流程将为您跟踪资源。必要时它将重新排列应用程序。

不变的基础设施

借助协调器中的自动故障转移处理，您可以按需在云中运行自定义映像。当您需要更新时，只需构建新映像，将启动配置设置为立即使用该映像，然后滚动即可。一切都会为您处理：

1. 使用新配置创建新服务器。
2. 杀死一台正在运行的服务器。
3. 您的协调器会将所有内容移至其他计算机（包括新计算机）。
4. 如果还有旧服务器，请转到1。

操作更简单

• 没有足够的资源？将新计算机添加到群集。
• 需要更多应用程序实例吗？增加数量并继续。
• 监控吗 做完了
• 日志管理？做完了
• 机密？你猜怎么着。

TL; DR重点不是关于Docker，而是关于编排。Docker只是tarball / fat JAR的扩展版本，是正确编排所必需的。

例如，以下是2014年发布的博客文章中的一些论点，其标题的名称与您的答案完全匹配：

• 更加灵活地将新技术注入环境
• 在提交最终的经过测试的代码然后使其在最终的生产服务器上运行之间，仍然存在着巨大的痛苦点。Docker大大简化了最后一步
• 不管您运行的是哪种Linux版本，Docker都能轻松保留旧版OS

来自：https : //thenewstack.io/why-you-should-care-about-docker/

如果您在docker容器中运行生产，则至关重要的是，这些容器由在其上运行应用程序的开发人员来制造。还有谁是更好的地方，知道需要什么外部依赖，依此类推……？

另外，在CD的任何阶段，流水线都可能失败，尤其是在docker映像构建步骤时，有时是缺少文件或需要lib的时候。

在工作中，我们向Docker介绍了所有开发人员，向他们介绍了构建dockerfile以便服务于他们的应用程序的基础知识，我们还简化了管道，因此仅添加名称和dockerfile即可自动在其上构建其应用程序。下一个推送，无论运行它的技术如何。

在devOps团队指导开发人员选择发行版之后（很多人都不了解alpine）之后，Docker quickstart确实是一个很棒的介绍。

我们的工作是为他们提供易于使用的工具，其余的工作由他们完成，以便在出现问题时可以对其进行修复。Docker实际上是开发过程的一部分，devOps团队为他们提供了符合我们需求的Docker映像，这些映像非常容易，因此只需几分钟就可以创建新应用并在没有帮助的情况下进行部署。

Docker得到了很多新闻和博客提及，这导致开发人员对使用它产生了兴趣。对于某些人来说，有兴趣使用新技术或了解事物的工作方式。对于其他人，则希望在其简历中添加关键字。无论哪种方式，开发人员对事情如何工作以及如何进行部署的了解越多，以后就不会感到惊讶。从我看到的结果来看，对此已有相当大的兴趣，因此鼓励它应该不难。

好吧，如果您曾经使用过VM进行测试，则可能需要尝试使用容器，而docker实际上是一个很棒的测试工具，它比LXC更容易使用:)