devops和docker_解码DevOps，Docker和Git

devops和docker

即使关于如何做到“正确”的公认标准仍然难以捉摸，DevOps还是现代IT的关键要素。 FutureAdvisor的DevOps主管Corey Quinn在运营和DevOps方面拥有丰富的经验。 在他在LinuxFest Northwest 2016上的两次演讲之前，我有机会与他交谈： Git和Docker中的 可怕想法 必定消亡：Docker教会中的异端 。

请继续阅读，进行有见地的聊天，在其中我们对DevOps，Git，Docker和开源进行主题讨论，并带有一点Corey的幽默感。

DevOps是一个热门且有时令人困惑的话题。 您如何定义它？ 这对您意味着什么？

五年前，“ DevOps”一词使您可以要求10个人定义该词并获得12个不同的答案。 如今，这并没有真正改变-如果有的话，您将获得15个答案，从理想的（“帮助打破文化筒仓”）到描述性的（“文化与工具的结合”）到愤世嫉俗的（ “一种通过简单更改标题即可为您的工资增加3万美元的方法”）。 今天，我将继续：DevOps是启动语义参数的好方法。

您能举一个正确完成DevOps的例子吗？ 使用了哪些工具？

很难再说：“这家公司确实钉住了DevOps，所以其他所有人都应该完全照做。” 那不是DevOps文化。 那是货物的培养 ，我们一直在看到这样的例子。 我所看到的最好的例子是那些意识到自己的20人工程团队不是Google数以万计的工程师的公司，或者那些在Facebook上真正行之有效的事情并没有映射到他们今天正在从事的工作。 因此，他们充分利用了其他商店的优势，并将其打造成独特的商店。 我希望我可以说存在“ DevOps in a Box”的存在-我很乐意将其出售给您！-但事实并非如此。

告诉我们我们不应该如何进行DevOps。 你有最喜欢的恐怖故事吗？

我所遇到的对DevOps文化的最严重的误解是一家商店，预计人们会花一半的时间从事运营任务，而另一半的时间则用于公司核心应用程序的开发。 那不是DevOps。 那是两个不同的工作。 毫不奇怪，团队中的每个人都至少失败了其中之一。

您现在看到什么趋势，尤其是在云和容器化的情况下？

不变的基础设施的兴起是一个共同的主题，但我更倾向于将其视为短暂的基础设施：根据设计，现在存在的事物不会在10分钟之内消失。 您如何在不不断关闭传呼机的情况下进行监控？ 您如何诊断间歇性问题，该问题最后一次发生在容器中，该容器在问题出现在雷达上时已被重新安排到另一个节点？ 容器和云要求我们重新思考比使用的交付技术更多的东西。 他们迫使我们重新思考我们如何看待环境以及我们关心的是什么。

您已经说过，Git在DevOps工具中越来越重要。 是什么使它变得至关重要？

如果没有其他原因，Git很重要，因为它是当前大多数商店中版本控制的事实上的标准。 版本控制的更大范围很重要，因为它直接表明了“基础结构即代码”的思维方式。 在更改某项内容之前先了解代码的样子，确定更改某项内容的时间和原因，并提供异步工作流模型-所有这些对于我们作为操作人员比手动配置服务器或交换机做得多的世界来说至关重要。 我将走得更远：如果没有Git或类似的工具，对于大多数环境，从功能上讲，不可能以任何合理的方式扩展到一千个节点。

您发现哪些Git集成工具有用？

当您说“ Git工具”时，我想到的是有助于减轻Git恐惧感的事物。 为此，Joey Hess的myrepos非常擅长简化大量Git 仓库的管理和更新。 Githug （Ruby的宝石）非常擅长教授Git如何应对有趣的挑战。 当然，对于大多数自动生成的结果， Random Git手册页生成器似乎很合理。 Git是一种非常简单的工具，很快就让位于可怕的复杂性。

在您的演讲中， Docker必须死：Docker教堂中的异端邪说 ，为什么您说保持谨慎很重要？

在本行业中，有一种令人不安的倾向，就是抛弃经时间考验的工具，以支持本周的闪亮新玩具。 确保您针对自己的用例而不是其他人的用例进行优化非常重要。 如果您最终想解决一些问题，而当您自己稍微接近20个节点时，问题便会扩展到200,000个节点，那么您可能已经失去了情节。 我演讲的重点不是说Docker是一种可怕的技术，而是事实。 但是，重要的是要对基础架构中发生的事情，其工作方式以及失败之前遇到的情况有一个了解。

您最推荐的三种容器最佳做法是什么？

我的第一个最佳实践是不要使用容器。 当您回来说：“太荒谬了！由于X，Y和Z的原因，这是对我们用例的最佳解决方案”，您很有可能已经对此进行了充分的思考，以至于您不会盲目地跳流行起来。 请记住，最佳做法并不适用于所有情况！

我的第二个最佳实践是确保每个人都全面了解您的新体系结构。 当开发人员为您提供3TB的容器（因为它包含数据库的完整副本）时，在某处出现了通信错误。

我的第三个最佳实践是考虑容器化将对当前环境产生的影响。 在迁移到更不变的模型时，我们在早期发现的发现是，我们的许多无状态实例并不像我们认为的那样几乎没有状态。 硬编码的IP地址，写出的日志文件，“特殊”主机运行着被遗忘的特定任务-在传统环境中堆积了很多杂物。

作为SaltStack的贡献者，Salt在诸如Docker之类的容器化技术之间有何关联？

这是一个很好的问题！ 我们将搁置这样一个事实，即Kubernetes（一种流行的容器调度程序）是建立在SaltStack之上的，而是在配置管理的背景下讨论不可变的基础架构。 即使在您所有基础架构都不可变的世界中，业务流程协调仍然是一个未解决的问题。 此外，只有极少数的商店符合该定义的资格-几乎每个人都在纯配置管理和纯金色映像之间徘徊。 您很有可能在您的环境中至少有一些短暂的或不可变的节点。

翻译自: https://opensource.com/business/16/4/linuxfest-northwest-interview-corey-quinn

devops和docker