基础架构即代码和TDD

11

作为代码的基础架构告诉我们使用自动化构建的工具。大。像工具ansible，厨师，木偶，盐栈以及其他推动我们写作基础设施长相怎么样，而解决分歧。

在Salt Stack中，这些位称为状态。如果状态与现实不符，该工具将为我们解决。换句话说-我们正在为基础架构编写测试，如果测试失败，该工具将自行修复。至少那是主意。

XP教我们如何使用TDD，问题是它是否适用于基础架构？工具表明确实如此。

我可以想象几种非常有用的测试类型。

我们编写与部署的服务捆绑在一起的冒烟测试，以确保端到端的部署服务正常运行。这将是一个API调用或/和systemctl检查，以确保我们刚刚部署的内容能够正常工作。由于诸如ansible之类的工具具有确保服务正在运行的状态，因此许多功能都可以在相同的状态下涵盖。

有一个项目Molecule允许针对docker或另一个临时虚拟化引擎运行单独的角色（如Ansible所说的那样）。这迫使角色分离，并允许在处理角色时将其与剧本隔离地执行。测试通常允许模拟该角色应该使用的变量。但是，其他示例似乎是ansible引擎的副本（声明文件属于用户...）。

ThoughtWorks的高科技雷达，现在推崇一样的工具INSPEC，serverspec或戈斯用于验证服务器是否满足规范。但是我们正在编写规范，不是吗？

如果我们以状态/角色描述基础架构，那么进一步测试基础架构是否有意义？我想这可能会在较大的组织（由一个团队提供规范并遵循其他规范）中变得更加必要，或者如果有大量角色，也许您想运行其中一部分并从测试中获得快速收益？我很努力地想知道，如果您对相同的问题有一个角色/状态，为什么还要编写测试。

— 杰克·里奥
source

6

简而言之，我看到针对您的基础结构的两类测试：1）它是否具有运行应用程序所需的一切，以及2）它没有任何多余的东西。

首先，您可以将实际软件的测试套件视为基础架构的一种“元测试”。只要您为每次测试运行从头创建基础架构，并且测试套件完全在该基础架构上运行（即，不使用外部服务），那么整个套件都是绿色的事实意味着您所编写的基础架构也已足够。

其次，尤其是从安全性角度来看，您可以针对基础结构编写测试。即，如果基础结构的一部分是运行Linux的VM，则可以编写一个测试，对该VM进行端口扫描，以确保没有意外打开的端口，这可能是由于意外的apt-get install副作用安装的。或者，您可以编写测试来检查在适当的测试套件完成后是否更改了所有意外文件。或者，您可以检查ps您的VM或Docker容器的输出中是否存在意外的进程等，构建白名单等，从而在某些第三方包在某些升级中以未记录（或未引起注意的方式）发生更改时得到自动通知。

无论如何，第二种测试在某种程度上类似于经典操作设置中的测试，即加强服务器并检查入侵，避免完全使用资源等。

— no
source

所以过了一段时间，这正是我的立场。由ansible执行的部分不会自己进行测试，但是会使用测试这些动作的副作用goss。因此，例如，RPM已安装（可安装），然后测试是否放置了预期的默认文件，或者服务正在运行并正在侦听特定端口。我不想自动解决此问题，但会收到通知并停止进度。当然，Ansible也可以为您测试系统，您只需要明确说明一下即可，但是在我们的案例中，我们使用它goss来测试容器内的服务行为

— JackLeo

1

恕我直言，为IaaC状态规范完全涵盖的项目编写TDD测试是相当多余的。这样做意味着IaaC的有效性值得怀疑-如果这样做，您为什么要使用它？

从不同的预期IaaC本身（如果/如果正确完成的话）来看，它包含已测试并被认为可靠运行的功能。这是什么使其吸引人，以及使编写TDD匹配测试变得多余。

例如，指定已安装SSH的系统的IaaC配置已经包含了对正确安装SSH的可靠检查，如果没有，则包括正确安装SSH的机制。这将进行TDD测试，以检查SSH是否冗余安装。如果您的IaaC配置还指定要启动sshd并在特定端口上侦听，则针对sshd运行和侦听相应端口的TDD测试也将是多余的。

请注意，我的答案不是针对TDD或其他任何类型的测试，这些测试将检查您的IaaC配置整体是否符合特定目的。这仍然有效，并且可以在该IaaC规范制定过程中用于TDD，CI或类似检查中-我相信@AnoE的答案适用于这种情况。

— 丹·科尼莱斯库（Dan Cornilescu）
source

您是否采用相同的想法来确保从外部配置文件中解析的特定自定义端口上启用了SSH（或其他任何功能）？这不是基于测试的单元，而是新颖的逻辑。

— 乔恩·劳里德森

1

如果支持的话，它应该是IaaC的一部分。如果不是，则此讨论实际上不适用。是的，这可能会滑入IaaC可以涵盖的范围，但这是一个不同的讨论。

— Dan Cornilescu

1

我还假设我们不在需要冗余检查的环境中-在某些情况下，可能需要遵循完全不同的代码路径甚至基础结构的冗余检查。

— Dan Cornilescu

1

似乎每个人都假设IAC工具始终按预期运行，但是我可以（根据我自己的经验）知道情况并非总是如此，否则单元测试实际上是无用的。

我记得有一张图片说“ Ansible剧本已经跑了，一切都很好”，背景中有一栋建筑物在烧毁...

从我的角度来看，运行声明性状态并使服务器处于此实际声明状态是至少两种不同的经历，至少是经历过两次。

广泛且异构的环境，分布在多个DC上，可以通过公共网络访问...等等。有多个原因导致无法完全或部分应用状态。

由于所有这些原因，单元测试仍有空间，可以让人们获得实际服务器状态的快照，这又可能与目标状态有所不同。

因此，我想说是的，即使在IAC管理的环境中，单元测试也很有用。

编辑

IaC代码库的dev分支的非回归方面如何？所以您会在dev分支中对代码进行更改，然后将其合并到prod分支中，希望不会破坏所有内容？单元测试是如此有价值，并且通常易于实现，我不明白为什么没有这种功能就可以编写代码。

参考（对此表示歉意）：https : //fr.slideshare.net/logilab/testinfra-pyconfr-2017

— 码头
source

1

至少有礼貌地添加一些反对意见，您不认为反对投票人吗？尤其是在这样的问题上，辩论可能会非常有益，甚至具有建设性。

— 码头

我认为您的回答语气对与这个问题有互动的每个人都具有攻击性，而且您没有以自己的榜样提供任何参考，也没有描述任何观察到的故障是拒绝投票的原因。您最终还是说出了与其他答案相同的说法，在置备系统中进行了烟雾测试，以确保系统正常运行，大多数系统都会因无法将系统收敛到所需状态而失败。关于您的编辑，通常是在分阶段部署并确保烟雾测试通过之后进行合并...

— Tensibai

我绝对不打算变得好斗，我这里没有使用我的natibve语言（我想这很明显:)）。

— 码头

如果您愿意，我们可以在DevOps Chat中讨论它，我想几年前我在devoxx活动上看到了这个演示文稿或类似的演示文稿。我稍微不同意调用该单元测试，因为它是功能测试。

— Tensibai

我的开发团队中的一些人告诉我，这完全不是单元测试，我不是开发人员，所以我称此单元测试可能是错误的，肯定是

— 码头

1

以我的经验，Dev和Ops之间的主要区别之一是“繁重的运行时依赖性”。安装软件包在很大程度上取决于存储库，网络或有效密钥，或者说实例化一个新的云服务器-这取决于您的提供程序资源。

就服务器供应而言，即使您没有更改供应代码，映像在大多数情况下仍有效，但有时无效。因此，我认为测试对于提供工作图像确实至关重要。

如果您在单台服务器上使用，情况会变得更糟……您将如何在整个网络设置中测试可达性？包括DNS解析，路由和防火墙？即使您的IaaC提供者API可以按预期工作（我在这方面已经看到了有线问题），但在这种情况下，我还是非常喜欢TDD。

因为我在这一领域没有找到任何测试工具，所以我们在业余时间写了一个：https : //github.com/DomainDrivenArchitecture/dda-serverspec-crate

因此，我认为TDD在DevOps世界中确实很重要！

— 杰格
source