Capistrano在木偶或厨师之上的必要条件是什么？
我的回应是发布指向Noah Gibbs的链接”文章“我们需要Capistrano和Chef吗？”。我个人仍然同意Noah的观点，它最适合用于：
使用Capistrano之类的专业部署工具进行部署。配置管理的厨师。
每种类型的工具用来完成其任务的基本方法都大不相同：
配置管理工具-与创建和配置有关。保持系统的理想状态，它们本质上是固有的。配置管理工具的例子包括Chef，Puppet，Ansible，PowerShell DSC，Salt Stack。管理哪个版本是“当前”版本，它们本质上是必不可少的。部署工具的示例包括Capistrano，Octopus Deploy，Deployer和Command.io。
我相信配置管理工具可以完成部署工具的工作，对于不可变基础架构，它们是最合适的用于工作的工具，因为不需要维护目标上的软件版本。
问题：诸如Chef，Ansible和Puppet之类的配置管理工具已经成熟到可以同时满足这两种要求的程度幂等和命令式模型？
#1 楼
在这种情况下，典型的建议应立即适用：使用正确的工具完成工作。并实际上由于各种原因而成为工具集：具有很酷的功能，扩大客户群，增加收入等。例如，许多文件管理工具包括图像查看功能，许多图像处理工具包括文件管理功能。您可以随意移动文件，也可以使用其中任何一种工具查看图像。
因此，很有可能整个软件开发过程的整个部分都被多个工具覆盖/重叠（设置），即使它们的主要功能/功能有所不同。 。包括主观性/偏好/便利性。
使这个问题主要基于观点；）
评论
我完全同意！越来越多的组织正在使用此正确的工具来开发“ DevOps工具链”。有关更多信息，此Wiki页面在讨论不同的工具/工作方面做得不错：en.wikipedia.org/wiki/DevOps_toolchain
–卡尔·哈纳吉（Karl Harnagy）
17年4月4日在16:22
我要补充的是，您将工具的使用范围扩展到其主要用途以外的地方越多，将花费更多的精力。您也许可以使用某些工具进行部署和配置，但是很有可能它将比仅使用两个工具做更多的工作（或需要采取最佳做法）。
– jschmitter
19年2月12日在18:32
#2 楼
配置管理工具用于使系统进入已知状态。部署工具将新程序文件和程序数据部署到系统。归根结底，这两种类型的工具都会进行以下组合：确定系统的当前状态。将文件传输到系统。
添加或更改持久性数据（例如配置文件，数据库数据，注册表设置）
启动或重新启动程序。
配置管理工具具有用于指定系统状态的声明性语言。部署工具具有命令性语言，这些命令告诉系统要做事。 DevOps人员需要同时执行这两项操作。
使用部署工具Capistrano，使用其语言告诉系统以确保Web服务器处于活动状态很笨拙。您必须发出命令以重新启动Web服务器，然后发出另一个命令以检查Web服务器是否已启动。使Web服务器进入已知状态很费力。
使用配置管理工具Ansible，重新启动Web服务器很麻烦。该语言使您可以告诉Web服务器处于“启动”状态，但是如果您特别希望重新启动它，则必须将其状态设置为“重新启动”。但是没有简单的方法来检查Web服务器是否已重新启动。这是Ansible中的一次失败，无法启用一次性操作。
有些人更喜欢用一种工具完成两种工作，并且在粗糙的边缘工作。其他人则更喜欢使用两种工具来完成几乎相同的事情，但是没有粗糙的边缘。要回答这个问题，“适当性”是一个品味问题。这个答案解释了为什么。
评论
我同意Capistrano在这种情况下会有些尴尬。它通常用作ssh上远程执行的ruby脚本/ snippets / lambda的名称空间。您在Ansible上的部分不正确。您可能需要对其进行一些研究并加以修复。好的第一篇文章，但请多做点工作。
–吉里·克劳达（Jiri Klouda）
17 Mar 27 '17 at 4:44
@JiriKlouda Ansible部分出了什么问题？您是不是要通过注册变量来检查Web服务器是否已重新启动，所以该节不是简单的方法？
–David Vasandani
17-4-15在17:31
有多种方法可以做到，答案的作者只是不知道。随意将其变成单独的问题，因为注释不是获得技术答案的好地方。
–吉里·克劳达（Jiri Klouda）
17年4月15日在23:21
#3 楼
TL; DR：只需使用Ansbile，它既是配置工具又是部署工具：)有几种类型的部署：
基于应用程序（文件，档案）程序包）
基于容器（包括VM，栖息地，LXC，Docker）
基于函数（微服务/ Lambdas /函数）
在这种情况下，我假设我们只谈论应用程序服务器上的更新。
要进行部署，您需要进行两件事：
正确的文件或程序包需要移至服务器。
需要更改配置和服务状态。
对于（1），您现在可以使用多种策略：
工件存储库/同步
软件包存储库/软件包管理器
版本控制系统/更新+编译（可选）
文件传输协议（scp，rsync，ftp）
部署工具
对于（2），您可以使用：
配置管理工具
部署工具
因此，尽管部署工具是一种实现方法部署于一体，它们并不总是最佳策略。有时您想结合使用这些方式进行部署。您很可能至少已经在服务器上使用了程序包管理器。无论如何，您很可能会运行配置工具。某些配置工具的问题是在多台服务器之间进行了适当的编排，但是现在，即使Chef和Puppet都能很好地做到这一点。 Ansible一直擅长于此。
根据个人经验，我使用了所有组合，但是目前我们使用Capistrano进行部署，使用Ansible sync进行配置管理，并使用VCS和软件包存储库进行文件传输，但是Capistrano出现了问题，我们计划将其转移到Ansible上以在部署，维护和配置管理上进行统一。
评论
我在Ansible和Capistrano上的经验将使我得出相同的结论。我只是和Ansible一起去。关于Ansible的好处是，它的“期望状态”声明很好地映射到基本命令性命令。
–杰伊·戈德斯（Jay Godse）
17 Mar 29 '17 at 14:12
人们有时会忽略围绕配置管理工具的社区贡献。 Ansible的社区组件（除DebOps外）有一些值得注意的例外，但还不如Chef和Puppet那样完善和功能完善。作为衡量，我发现Puppet和Chef可以“应用”和不应用配置指令（执行或撤消一组更改），而Ansible在“应用”部分很出色，但在“应用”部分却不太出色取消应用”部分。
–杰西·阿德尔曼（Jesse Adelman）
18年4月20日在0:06
#4 楼
应用程序部署很难确定，因为它有很多子问题。配置管理系统在建模任务方面表现出色，这些任务可以收敛并且可以与“系统的期望状态”一起使用。在应用程序部署的上下文中，这非常适合诸如将位部署到计算机，管理配置文件以及设置系统服务之类的事情。这是非常不利的，因为它本质上是过程性的，尤其是数据库迁移和服务重启。我通常会尝试将收敛逻辑放入Chef中，并让外部过程工具（在我的情况下通常为Fabric）处理剩余的几部分，并对实际收敛进行排序。最好同时使用它们。#5 楼
对于软件和将代码部署到现有服务器或Docker容器内部的问题，答案相对简单-不，您不需要两者，但是如果其他工具或实用程序能增加价值并且是完成任务的正确工具，则可能需要两者但是，在部署服务器和操作系统时，事情会变得更加复杂。弹性化的环境。您的配置管理系统无法轻松地为您进行netboot和启动服务器，也无法在部署期间和部署后或某些情况下（例如，许可和权利）为您管理存储库，软件包和更新/补丁。对于Amazon Web Services，在大多数情况下，这可以通过API方便地进行管理，但是对于那些必须管理自己的数据中心的人来说，这不是一种选择。因此，在部署Katello方案时，Foreman项目（以及重新命名为Red Hat的Red Hat）发现有必要将Katello，Candlepin和配置管理器（例如Ansible，Foreman或Puppet）捆绑在一起。
因此，尽管您可能可以使用配置管理工具在房屋的Dev一侧进行软件代码部署，但在Ops一侧却有很多情况可以解决。 “不，配置管理工具不适合用作部署工具”这样做将需要对轮子进行认真的重新设计，这是不切实际的。您必须改为使用配置管理工具在另一个工具中启动部署。
评论
不管是否，厨师都会像处理部署一样优雅地处理Capistrano，在Windows下部署巧克力类软件包，并安装所有众所周知的软件包（deb，rpm，msi，nullsoft等）。它确实给包装方面带来了一些负担，这是栖息地要解决的问题，但这是一个相当能够处理部署的配置管理系统，我可以看到它每周在包括生产在内的多种环境中进行大约40次部署，这可以说明这一点事先编写代码很麻烦，但是与使用任何其他工具进行的工作相比，这并没有那么高。
–滕西拜
17年5月22日在21:07
实际上，Foreman既不是供应，部署或配置管理系统。它只是一种皮肤，提供基于Web的UI和框架，将配置管理系统（木偶），许可证管理系统（candlepin），存储库和补丁管理系统（Katello）以及预配/部署系统（kickstart）粘合在一起。它在所有这些不同项目的前端并将它们粘合在一起。尽管几乎所有配置管理系统都可以安装软件包，但它们不能做的是以类似于WSUS服务器的方式提供补丁程序管理。
–詹姆斯·谢威（James Shewey）
17年5月23日在2:25
或固定或部署特定版本的软件包，包括不在上游仓库或混搭仓库中的软件包。我的观点是，如果Red Hat / Foreman / Katello认为仅靠配置管理系统是无法做到的-最显着的原因是它缺少值得注意的配置/部署部分。
–詹姆斯·谢威（James Shewey）
17年5月23日在2:33
我读错了关于卡特洛的句子，我不好。为了完整起见，第一条评论是：)
–滕西拜
17年5月23日在5:05
评论
从4.0开始，Ansible总是可以的，Puppet理查德，感谢您最近提交的所有高质量问题。我非常感谢您在Beta版期间为预填充网站付出的辛勤工作。提出好的引导性问题很难，而且您真的很擅长做什么。
@JiriKlouda非常欢迎您，在我的计算机上确实有一个“ DevOps SE” post-it™提醒我在遇到问题时发帖。