chef-infra - Artifactory、Chef 和 Chocolatey 如何协同工作？

Question

我们正在实施 CI/CD 管道，并使用 TFS 作为我们的代码存储库和构建和发布工具。我有以下具体问题：

1. 我们目前将构建过程中需要的库和第 3 方工具存储在代码存储库中。我们想分析存储和访问 3rd 方工具和库的其他方式。
   • Artifactory 是存储它们的正确工具吗？据我了解，Artifactory 只能用于存储可以丢弃和重新创建的构建工件。
   • 还是使用 Chocolatey 是更好的选择？据我了解，我们需要从我们的 3rd 方工具和库创建 Chocolatey 包。在哪里：
     • 这些包的来源，例如（.exe、.dll、.zip、.msi）通常驻留吗？
       • 在 UNC 文件位置？
       • 或者在像 Artifactory 这样的二进制存储库中？
       • 使用二进制存储库来存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，并且每个新版本都会增加存储库的大小。
     • Chocolatey 包装本身是否存在？
       • 在 UNC 文件位置？
       • 或者在像 Artifactory 这样的二进制存储库中？
       • 使用二进制存储库来存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，并且每个新版本都会增加存储库的大小。
2. 如果我们将 3rd 方工具和库存储在我们的代码存储库之外
   • 我们需要使用 Chef 和 Chocolatey 来访问它们吗？
   • 或者我们可以使用 Chocolatey 直接从 TFS 访问它们，而不必在构建过程中使用 Chef？
3. 我是否正确地认为 Chef 主要用于在开始构建过程之前使用所需的软件和环境变量设置构建环境？

标签： chef-infraartifactorydevopschocolatey

Answer 1

让我们看看我是否可以为你分解这个。

1. 我们目前将构建过程中需要的库和第 3 方工具存储在代码存储库中。我们想分析存储和访问 3rd 方工具和库的其他方式。

   • Artifactory 是存储它们的正确工具吗？

是的，Artifactory 和其他软件包存储库服务器通常有一个二进制/原始存储库，这将是一个不错的选择。将 Artifactory 视为放置您的生产使用工件的地方。因此，这些库、第 3 方工具、第 3 方软件、模块等都可以存储在 Artifactory 中不同类型的存储库中。Artifactory 将是一个企业级的包存储库管理器，经过优化可以做到这一点，处理高可用等等。您可以在此处存储、保护和部署二进制文件、包、软件等。这可以用于开发、测试、阶段和生产环境。

• 据我了解，Artifactory 只能用于存储可以丢弃和重新创建的构建工件。

我认为这有点偏离 - 很接近。您可以存储可以丢弃和重新创建的构建工件，但您也可以在那里存储更多。以这种方式陈述它并没有真正做到它实际上可以做的事情。

• 还是使用 Chocolatey 是更好的选择？

这不是 Artifactory 的竞争选择。Chocolatey 包可以存储在 NuGet 类型存储库的 Artifactory (Pro) 中。二进制文件可以在 Chocolatey包中，也可以在二进制/原始存储库中。

Artifactory 是一个包存储库，其中 Chocolatey 是 Windows 的包管理器（软件管理和部署）。

据我了解，我们需要从我们的 3rd 方工具和库创建 Chocolatey 包。在哪里：这些包的来源，例如（.exe、.dll、.zip、.msi）通常驻留在哪里？

• 在 UNC 文件位置？
• 或者在像 Artifactory 这样的二进制存储库中？
• 使用二进制存储库来存储构建时依赖项是正确的方法吗？

您忘记了最常用和推荐的方法：

• 在包装本身

Chocolatey 包本身是最推荐保存包所代表的二进制文件的地方。这是最确定性和最可靠的包装方法。

问题是您可能将社区包存储库视为打包的示例 - 我们建议不要这样做，因为它不代表但可能有 5% 的包。我们不建议采用这种方法，因为它不是一种可靠的方法。

• 它需要永久驻留在那里，并且每个新版本都会增加存储库的大小。

这是真的，但是 Artifactory 确实有一种剔除方法（我相信）并且它针对这些类型的场景进行了优化。我们在https://chocolatey.org/docs/how-to-host-feed#commercial-repository-system-requirements浏览了针对不同商业存储库解决方案的系统要求建议。

• Chocolatey 包装本身是否存在？

  • 在 UNC 文件位置？

他们绝对可以，但请记住权限如何与文件共享和 Windows 权限一起使用 - https://chocolatey.org/docs/how-to-host-feed#local-folder-permissions

• 或者在像 Artifactory 这样的二进制存储库中？

不，那将是 Artifactory Pro 中可用的 NuGet OData 存储库。是的，NuGet Artifactory 存储库将是一个好地方，并且可以为不同的环境、权限等使用多个存储库。任何对您的环境有意义的东西。

• 使用二进制存储库来存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，并且每个新版本都会增加存储库的大小。

我认为这是在其他地方处理的。

2. 如果我们将 3rd 方工具和库存储在我们的代码存储库之外

   • 我们需要使用 Chef 和 Chocolatey 来访问它们吗？
   • 或者我们可以使用 Chocolatey 直接从 TFS 访问它们，而不必在构建过程中使用 Chef？

你通常可以做任何一个。如果您确实将 3rd 方工具放入软件部署包（又名 Chocolatey 包）中，您将需要 Chocolatey 来管理部署。

3. 我是否正确地认为 Chef 主要用于在开始构建过程之前使用所需的软件和环境变量设置构建环境？

我会说你误解了 Chef - 这是一个配置管理解决方案。它可以设置构建环境并将它们保持在所需的状态，但这会限制功能。Chef（和其他配置管理器）用于为您的基础架构（基础架构即代码）编写预期状态（期望状态），您可以在部署之前检查源代码控制并测试整个基础架构更改，可能使用持续集成（CI ) 像 Jenkins、TeamCity、TFS 这样的服务器（这会测试你的基础设施、测试驱动的基础设施等）等。对于开发人员来说这有点直观，但对于房子的运营方面的人来说，这都是更新的将这些开发实践带到运营中。我称之为现代自动化，但有些人称这种转变为 DevOps。

推荐

您可以使用 Chef + Chocolatey + Artifactory 解决方案来管理整个组织的软件和机器配置，而不仅仅是开发环境。我认为您可能正在从开发人员类型职位的参考框架中接近所有这些工具，因此只是在配置的上下文中考虑，而不是操作/系统管理员可能会的部署、配置等的长期管理看着。这些工具当然都增加了一些东西，但它们都是互补的，而不是完全竞争的解决方案。对于许多大型组织而言，将这些或类似组件部署到位会产生一个能够处理当今组织的关键基础架构需求的架构。