Puppet或Chef是否适合在多租户环境中管理非常基本的服务器配置？

9

这涉及多租户环境，例如小型托管公司。

Puppet（或类似产品）是否适合用于处理基本但重要的质量变化？例如：

更新DNS解析器（resolv.conf）
设置SSH密钥
更新NTP配置
配置snmpd
部署监视脚本，例如SNMP Perl扩展或Nagios脚本

我担心的是安全性和入侵性：

我不希望任何服务器都能看到它不应该看到的任何配置
我担心Puppet主服务器可能容易受到受到感染的服务器的攻击
我不希望Puppet进行不应做的任何更改，也不希望还原服务器上所做的任何手动更改。

我应该警告我，我从未在生产中使用过Puppet，只是在测试实验室中快速玩过游戏，所以我可能会以错误的方式来考虑！

puppet

— 西蒙·格林
source

6

尝试使用Ansible（ansible.cc）。可能是给你的。您的客户端上没有正在运行的代理。它增长非常快。

另一个非常好的替代方法是Salt Stack。

Ansible和Salt很容易理解，可以根据需要将它们用作命令行工具，例如分布式shell。

— 阿夫斯·托帕拉克
source

1

我知道我很久以前问过这个问题。您会很高兴知道这是答案。现在，我们使用Ansible每天自动部署10台服务器，并采用即发即弃的方式管理1000台服务器。一年多来一直很棒。

— SimonJGreen

9

是的，这肯定是可能的。不过，由您决定是否应该这样做。

关于您的查询：

1）足够公平。流量基于ssl，因此证书管理非常重要。也不要相信客户提供的与其身份有关的任何“事实”，因为客户可以更改这些事实。您要依赖客户端的ssl证书来提供服务器身份的身份验证。老实说，如果您正确使用了hiera之类的东西，并且避免在代码中使用大型的基于主机名的if块（您应该这样做），那么您会很好的。

2）不应该这样，假设您对其进行了修补。正确配置后，puppetmaster只会受到客户端攻击的一个很小的威胁。就是说，如果确实受到损害，后果会很大，因此请小心将其锁定。

3）这实际上是一个测试和部署问题。如果您有可靠的p代码，则不会破坏您的文件。进行排序确实需要一些时间，但对于基础知识（如您所需要的）来说，时间并不长。

— 西雷克斯
source

4

Puppet（或类似产品）是否适合用于处理基本但重要的质量变化？

是的，可以通过这种方式使用。我用它来支持外部客户端系统。

我不希望任何服务器都能看到它不应该看到的任何配置

如果您使用的是人偶，则一定不能启用自动签名。自动签名允许主机自动请求证书。您的配置和权限几乎可以肯定直接与证书中的CN绑定。您不希望随机计算机联机并能够声称它们实际上是具有所有秘密高安全性内容的系统。

如果您真的很偏执，可以调整人偶文件服务器设置以创建仅某些系统可以访问的共享。文件服务器访问基于证书。

我不希望Puppet进行不应做的任何更改，也不希望还原服务器上所做的任何手动更改。

有两种允许本地更改的方法。

我经常使用的一种方法如下。基本上，如果您将列表传递给source，则人偶会尝试列表中的每个项目。因此，我在列表中添加了第一项以指向本地文件。

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

另一种选择是利用符号链接。如果有人要使用人偶版本，他们会符号链接到文件的人偶版本。如果他们想在本地维护其配置，则不会创建符号链接。

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

另一种可能性是使用augeas进行行级更改，而不是更改整个文件。对您所做的更改要非常保守。

— Zoredache
source

1

3> Puppet或任何此类工具都没有自动撤消功能。您必须编写明确的代码才能撤消。此外，您可以研究puppet的环境功能，拥有一个测试新代码（可能是VM）的测试实验室，并使用代码查看。

— 现在不要
source

不完全正确。Chef会对/var/lib/chef默认情况下更改的任何文件进行备份（除非将资源配置为不保留任何备份，例如敏感数据），并且使用doc格式化程序，您会在终端输出上看到差异。

— Maciej Pasternacki

是的，Puppet也可以进行多个备份。但是您怎么知道要还原哪个备份？您将必须编写一些Chef / Puppet代码或外部脚本来实际执行该操作？对于非文件资源，例如还原到具有特定版本的先前软件包，该怎么办？服务如何？如果您有表示“确保正在运行”的代码，并且想要更改它，则必须将代码更改为“确保已停止”。

— 不现在，

这个想法是配置管理运行是单向的。没有受支持的回滚过程或功能全面的“空运行”（Chef中有一个Whyrun模式，它仅是建议/健全性检查，而不是完全模拟（请参阅blog.afistfulofservers.net/post/2012/12/21/ …以获得更详细的解释。）您不能取消用户密码等，这就是为什么我写“ not full true”的原因-不支持回滚，但是有一个安全/调试网，可以让您查看是否备份出了一些问题，您需要看一下。仅此而已，但仍然有用

— Maciej Pasternacki

事实证明，我听错了您的评论-的确，没有自动撤消，并且如果您想使它自动化，则需要编写明确的（很可能是错误的）代码。由于已回复原评论，因此我无法对其进行编辑-我在考虑灾难恢复而不是自动回滚。如果要查看自动回滚，请访问nixos.org，BTW。

— Maciej Pasternacki

1

我不希望Puppet进行不应做的任何更改，也不希望还原服务器上所做的任何手动更改。

对于使用Puppets File类型创建的配置文件，可以通过设置以下内容来实现：

replace => false,

我将其用于在应用程序第一次部署到服务器时生成一些配置文件，但是，对该配置文件的任何编辑都不会被Puppet覆盖。

但是，这确实违反了Puppet成为幂等部署脚本的原则。

如果可以的话，最好有一个单独的，不是由puppet管理的可编辑文件，而是由puppet管理的文件中包含这些文件。

— 达纳克
source

0

Puppet最适合配置相同的许多服务器。例如，编写公司提供的共享Web服务器的所有配置，然后创建该服务器的N个实例。之后立即对所有实例进行更改（例如，您发现需要为所有apache虚拟主机更改AllowOverride）将非常容易。您还可以将所有配置信息存储在一个地方，并在版本控制下进行管理。在完美的情况下，您将能够通过丢弃损坏的主机，用新主机替换，设置相同的主机名并签署所需的证书来处理硬件故障。其他所有事情都可以由Puppet完成。

但是，如果最终在两台主机之间几乎没有配置共享，那么使用puppet可能会比手动配置工作效率低。同时使用puppet管理服务器配置的一半，而手动管理另一半可能没有多大意义。

摘要：如果您可以为要管理的主机创建统一的结构化配置，Puppet是您最好的朋友，但是如果您必须处理每个服务（主机，虚拟主机，数据库），则Puppet不会添加很大的价值。

— 斯卡拉普
source