配置管理工具是否适合用作部署工具？

我没有回答这个问题：DevOps如何帮助改善软件托管程序？Tensibai的问题是：

在木偶或厨师的头上需要Capistrano是什么？

我的回应是发布指向Noah Gibbs的文章“我们需要Capistrano和Chef吗？”的链接。。我个人仍然同意诺亚的观点，它最适合：

• 使用专业的部署工具（例如Capistrano）进行部署。
• 使用专业的配置管理工具（例如Chef）进行配置管理。

每种类型的工具用来完成其任务的基本方法都非常不同：

• 配置管理工具 -与创建和维护系统的期望状态有关，它们本质上是固有的。配置管理工具的示例包括Chef，Puppet，Ansible，PowerShell DSC，Salt Stack。

• 部署工具 -与将软件版本交付到主机环境有关，它们提供的功能可以在多台计算机上维护软件的多个版本并管理哪个版本是“当前”版本，它们本质上是必不可少的。部署工具的示例包括Capistrano，Octopus Deploy，Deployer和Command.io。

我确实相信配置管理工具可以完成部署工具的工作，并且在不可变基础架构的情况下，它们是最合适的工具，因为不需要维护目标上的软件版本。

问题： Chef，Ansible和Puppet等配置管理工具是否已成熟到可以同时满足幂等和命令式模型的程度？

在这种情况下，典型的建议应立即适用：为工作使用正确的工具。

但是，如今，您也不能忽视软件工具将功能扩展到或多或少相关领域并实际上成为工具集的近乎致命的趋势，其原因有很多：拥有很酷的功能，扩大客户群，积累更多的收入等。

例如，许多文件管理工具包括图像查看功能，许多图像处理工具包括文件管理功能。您可以四处移动文件，也可以使用其中任何一种工具查看图像，效果通常都一样。

因此，即使它们的主要功能/功能有所不同，也有可能使软件开发过程的整个部分都被多个工具（集合）覆盖/重叠。

因此，它实际上可以归结为您希望在特定过程中实现的确切功能，以及一个或多个工具在您的上下文中完成工作的程度。包括主观性/偏好/便利性。

使这个问题主要基于观点；）

配置管理工具用于使系统进入已知状态。部署工具将新程序文件和程序数据部署到系统。归根结底，这两种工具都可以完成以下工作：

• 确定系统的当前状态。
• 将文件传输到系统。
• 添加或更改持久性数据（例如，配置文件，数据库数据，注册表设置）
• 启动或重新启动程序。

配置管理工具具有用于指定系统状态的声明性语言。部署工具具有命令式语言，该语言可告诉系统执行操作。DevOps人员需要同时执行这两项操作。

使用部署工具Capistrano，使用其语言告诉系统确保Web服务器处于活动状态很笨拙。您必须发出命令以重新启动Web服务器，然后发出另一个命令以检查Web服务器是否已启动。使Web服务器进入已知状态很费力。

使用配置管理工具Ansible，重新启动Web服务器很麻烦。该语言允许您告诉Web服务器处于“启动”状态，但是如果您特别希望重新启动它，则必须将其状态设置为“重新启动”。但是没有简单的方法来检查Web服务器是否已重新启动。这是Ansible中的一次失败，无法启用一次性操作。

有些人更喜欢用一种工具完成这两种工作，并且在粗糙的环境中工作。其他人则更喜欢使用两种工具来完成几乎相同的事情，但是没有粗糙的边缘。要回答这个问题，“适当性”是一个品味问题。这个答案解释了为什么。

TL; DR：只要使用Ansbile，它是两者的配置和部署工具:)

有几种部署类型：

• 基于应用程序（文件，档案包）

• 基于容器（包括虚拟机，栖息地，LXC，Docker）

• 基于功能（微服务/ Lambdas /功能）

我假设在这种情况下，我们仅谈论服务器上的应用程序更新。

对于部署，您需要发生两件事：

1. 正确的文件或软件包需要移至服务器。
2. 配置和服务状态需要更改。

现在对于（1），您可以使用多种策略：

• 工件存储库/同步
• 软件包存储库/软件包管理器
• 版本控制系统/更新+编译（可选）
• 文件传输协议（scp，rsync，ftp）
• 部署工具

对于（2），您可以使用：

• 配置管理工具
• 部署工具

因此，尽管“部署工具”是一种可以进行全部部署的方法，但它们并不总是最佳策略。有时您想结合使用这些方式进行部署。您很可能至少已经在服务器上使用了程序包管理器。无论如何，您很可能会运行配置工具。某些配置工具的问题是在多台服务器之间进行了适当的编排，但是现在，即使Chef和Puppet都能很好地做到这一点。Ansible一直擅长于此。

从个人经验来看，我使用了所有组合，但是目前我们使用Capistrano进行部署，使用Ansible sync进行配置管理，使用VCS和软件包存储库进行文件传输，但是Capistrano出现了问题，我们计划将其转移到在Ansible上统一用于部署，维护和配置管理。

应用程序部署很难确定，因为它有很多子问题。配置管理系统在建模任务方面表现出色，这些任务可以收敛并且可以与“系统的期望状态”一起使用。在应用程序部署的上下文中，这非常适合诸如将位部署到计算机，管理配置文件以及设置系统服务之类的事情。极其不利的是固有的过程，尤其是数据库迁移和服务重启。我通常尝试将收敛逻辑放入Chef中，并让外部程序工具（在我的情况下通常为Fabric）处理剩余的少量数据并对实际收敛进行排序。

因此，基本上，您应该同时使用它们最擅长的部分。

对于软件和将代码部署到现有服务器或Docker容器中的问题，答案是相对简单的-不，您不需要两者，但是如果其他工具或实用程序能够增加价值并且是完成任务的正确工具，则可能两者都需要，但是在部署服务器和操作系统时，事情变得更加复杂。

DevOps心态的一个附加值是将基础架构视为代码，并在高度弹性化的环境中频繁部署或破坏虚拟机甚至裸机。您的配置管理系统无法轻松地为您进行netboot和启动服务器，也无法在部署期间和部署后或某些情况下（例如，许可和权利）为您管理存储库，软件包和更新/补丁。

对于Amazon Web Services，在大多数情况下，这可以通过API方便地进行管理，但是对于那些必须管理自己的数据中心的人来说，这不是一个选择。因此，Foreman项目（以及重新命名为Red Hat的Red Hat）发现在部署Katello Scenario时有必要将Katello，Candlepin和配置管理器（如Ansible，Foreman或Puppet）捆绑在一起。

因此，尽管你也许可以逃脱使用配置管理工具上的房子开发端软件代码部署，在在行动方面，有几种情况下，答案是一个响亮的“不，配置管理工具都没有适当地用作展开工具”。这样做将需要对轮子进行认真的重新发明，这是不切实际的。相反，您必须使用配置管理工具在另一个工具中启动部署。