流浪者置备外壳vs木偶vs厨师

本文介绍了流浪者置备外壳vs木偶vs厨师的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有以下设置：

• 许多不同的项目，它们是单独的git存储库，但大多数都具有相同的服务器配置
• 每个项目又依赖于许多其他项目，我们使用composer依赖管理器将它们放在一起（此处为PHP语言）。

我想使用Vagrant，并在每个存储库中包含一个Vagrant文​​件，因此我的团队成员可以克隆存储库，运行 vagrant up 并做好准备

我的问题现在针对配置。我需要安装一些工具和软件包，例如apache，git，mysql和几个php软件包，然后下载一些文件（例如最近开发的db dump），在/ var / www中进行所有设置，然后运行composer install命令。

因此，一种选择是使用经理使用厨师或木偶之类的食谱。 替代方法是编写一个bash文件并使用shell配置。

我对厨师/木偶的经验不多，所以自然地，似乎更容易使用shell选项，但从长远来看，我想了解一下这是否不是一个好的/可行的选择。

为什么对我来说，这是一个不好的选择木偶/厨师：

我知道我将不得不使用几种不同的配方，并且几乎总是将相同的配方用于不同的存储库，因此我将必须包括所有在所有存储库中。考虑有20个仓库，需要10个食谱，这意味着我将需要添加200个食谱作为git-submodule或类似的东西（每个团队成员也需要克隆存储库，然后克隆10个食谱存储库，然后为每个容器运行流浪汉项目）。相比之下，我只需要在shell脚本中创建一个小型存储库并将其克隆20次即可。

我可能会丢失一些内容，因此请告知我是否应该选择对于厨师/木偶，以及即使我的存储库都具有非常相似的服务器设置，为什么也有意义。

解决方案

以下文章关注还有另一个CM工具（ ansible ），但是我认为作者在解释从shell脚本过渡的好处方面做得很好。 / p>

devopsu/blog/ansible -vs-shell-scripts /

引用1：

让我真正感到惊讶的是，其中一些更著名的开发者的回应。他们基本上说：这真的很酷，但是由于我的手动安装/ shell脚本工作流程目前还不错，所以我可能不会读。

I有点震惊，但是一旦我考虑了几分钟，我意识到他们对CM工具的了解完全是理智和理性的。

quote 2：

对于他们来说，使用CM工具意味着需要数周的时间来学习复杂的概念，复杂的安装过程，并随着时间的推移维护该复杂的系统。他们在某种程度上意识到了好处，但是使用CM工具的成本似乎太高了，值得付出努力。

结束语总结了shell脚本的好处，我认为它们适用于所有CM工具，木偶，厨师，盐，ansible ...

• 哪种方法最有可能最终在源代码管理中？
• 哪种方法可以放心地安全运行多次？
• 哪种方法可以容易在多个服务器上运行？
• 哪种方法实际上验证（测试）服务器的正确性？
• 哪种方法可以轻松地针对某些服务器（网络，db等）？
• 哪种方法可以轻松地为您的配置文件提供模板？
• 哪种方法可以轻松地为您的整个堆栈提供支持？

希望这会有所帮助。

I have the following setup:

• Many different projects which are separate git repositories, but all have mostly the same server configuration
• Each project in turn depends on many other projects and we use the composer dependency manager to get them together (PHP language here).

I want to use Vagrant and include a Vagrant file in each repository, so my team members can clone a repository, run vagrant up and be ready to go.

My question is now directed towards the provisioning. I need to install several tools and packages like apache, git, mysql and several php packages, then download some files (like a recent development db dump), set everything up in /var/www and run the composer install command.

So one option to do this is using a manager using recipes like chef or puppet. The alternative would be to write a bash file and use shell provisioning.

I have not much experience with chef / puppet, so naturally, it seems easier to use the shell option, but I want to understand if this is not a good / viable option in the long run.

Why to me it seems a bad approach to go with puppet / chef:

I understand that I will have to use several different recipes and will almost always use the same recipes for my different repositories, so I would have to include all of them in all the repositories. Consider having 20 repos and needing 10 recipes, that means that I will need to add 200 recipes as a git-submodule or alike (also each team member needs to clone the repository, then clone 10 recipe repositories and only then run vagrant up for each project). In contrast, I would just need to have a small repo with my shell script and clone it 20 times.

I am probably missing something, so please advice whether I should opt for chef / puppet and why it makes sense even if my repositories all have a very similar server setup.

解决方案

The following article concerns yet another CM tool (ansible), but I think the author does an excellent job of explaining the benefits of transitioning away from shell scripts.

devopsu/blog/ansible-vs-shell-scripts/

quote 1:

What really surprised me was the response from some of these more famous devs. They basically said, "This is really cool, but I probably won't read it since my manual-install/shell-script workflow is fine for now."

I was a little shocked, but once I thought about it for a few minutes, I realized that their choice was perfectly sane and rational given what they knew about CM tools.

quote 2:

For them, using a CM tool meant weeks of effort learning complex concepts, struggling with a complex installation process, and maintaining that complex system over time. They were somewhat aware of the benefits, but the costs of using a CM tool just seemed too high to make it worth the effort.

The benefits over shell scripts are summarized at the end and I think they apply to all CM tools, puppet, chef, salt, ansible...

• Which method is most likely to end up in source control?
• Which method can be run multiple times safely with confidence?
• Which method can easily be run against multiple servers?
• Which method actually verifies (tests) your server for correctness?
• Which method can target certain servers easily (web, db, etc)?
• Which method supports easily templating your configuration files?
• Which method will grow to easily support your whole stack?

Hope this helps.