持续交付自动化配置环境_关于连续交付的注意事项–配置管理

最新推荐文章于 2022-05-06 11:38:38 发布

danpu0978

最新推荐文章于 2022-05-06 11:38:38 发布

阅读量180

点赞数

文章标签：数据库 python java 大数据编程语言

原文链接：https://www.javacodegeeks.com/2013/02/notes-on-continuous-delivery-configuration-management.html

版权

持续交付自动化配置环境

概述我将继续在我之前的文章中开始的关于持续交付的主题：关于持续集成的说明；这次，我们将开始研究第一步，也是最重要的一步，即配置管理。 用作者的话说（以下资源）：

配置管理是指所有工件……及其之间的关系被存储，检索，唯一标识和修改的过程。

配置管理涉及四个原则：

1.将所有内容保留在版本控制中

源代码控制仅适用于源代码， 版本控制适用于项目具有的任何工件类型：源代码，测试，数据库脚本，线框，高清晰度模型，构建脚本，文档，库，配置文件，发行计划，要求文档，架构图，虚拟机配置，虚拟机映像等。如果您还没有的话，我想挑战您如何改变您的怪异词汇。

我有一点野心。版本控制系统中存储的元数据可以访问您曾经存储的每个文件的每个版本，并可以促进分布式团队之间在空间和时间上的协作。

连续交付过程中的复杂程度取决于配置管理策略的成熟程度。如果绝对存储所有内容都不可行，或者需要太多工作和金钱，那么可以从一些工件开始（当然，还有源代码），您几乎会立即看到过程中的改进。

提倡频繁检入代码以及有用的提交消息的想法。在版本控制命令行工具中使用典型的' -m '开关，几乎所有人都支持它。

版本控制使您可以自由删除文件；最坏的情况是，您始终可以轻松地检索它。就像重构代码具有无限的“撤消”历史一样。

2.管理依赖性

依赖关系构成应用程序使用的任何外部库，组件和模块。例如：

JAR文件– Java或JVM语言
PEAR，PECL模块或PHAR文件– PHP
DLL – .NET
Ruby宝石–Ruby
绑定– Python
NPM – Node.js

在此类别下还将是配置操作系统的任何扩展或库。构建工具使管理依赖项变得容易（不容易）。我在使用Maven，Ant和Phing等工具方面取得了成功。最近还有很多其他吸引了人们的东西，例如：Gradle和Ivy。我建议使用Maven之类的工具，因为它可以通过设置软件包存储库在不同的机器上重新创建环境以及以集中方式管理依赖项。

3.管理软件配置

也许最重要的原则是配置管理要求您有一种策略，可以自动将配置属性注入到软件中。如果您打算支持不同的环境（质量检查，登台，预览和生产），这至关重要。可以注入配置信息：

在构建时或打包时：使用Maven读取属性文件并将配置信息注入其中。通常将其视为具有名称/值对记录的属性文件。这些在Java和PHP中很常见； YAML文件在Ruby和Python世界中很常见。 XML也是所有平台都支持的一个很好的竞争者。

在启动时：通常通过环境变量或命令行参数完成。

在运行时：说您将配置信息存储在数据库或外部系统中。然后，您的应用程序可以从Web或通过脚本获取配置信息并应用它们。为此，始终需要一些引导信息，例如：数据库连接和外部URI。

无论使用哪种机制，请确保所有内容均受版本控制。一个直接的问题是，我们如何存储诸如密码之类的敏感信息？这是一种方法：

John Resig：在源代码管理中保留密码

另一个方法是将密码与代码存储在一起，以便对其进行编译和混淆。这不是一个好习惯，尤其是在解释语言中。我建议至少使用安全证书，SSL密钥或加密信息。我成功实现的最简单的配置管理方法是通过如上所述的属性文件的构建时间注入。这些取决于以下内容：

应用程序
应用程序的版本
环境（质量检查，生产，UAT，预览，暂存等）

使用Maven，您可以在将配置信息打包到可部署的工件之前轻松地将配置信息注入到应用程序中。这是一种非常简单的好方法，因为所有配置都存储在版本控制中并使用文件系统，该文件系统在所有平台中均得到广泛支持。

免责声明：如果您实际上是在开发Java Applet（我不解释为什么有人仍然想这样做……），那么访问文件系统可能不是一个选择。在这种情况下，将您的配置存储在可以通过RESTful调用获取的外部系统中是一个很好的解决方案，到目前为止，所有提及的相同原理仍然适用。

要记住的一点是，请在开发生命周期的早期考虑配置管理。为您的组织创建模式，以便每个应用程序都以相同的方式进行操作：约定优于配置。通常，这是事后的想法，团队倾向于开发自己的临时配置管理策略。这将使您的Ops和DevOps团队很难真正实现自动化，浪费时间重新发明轮子，并且您很可能会犯其他人已经犯过的相同错误。

4.管理环境

环境的配置与应用程序的配置一样重要。您的应用程序可能需要特定的系统级别配置，例如文件句柄数，内存限制，防火墙或网络，连接池等。这对于正确使用非常重要，并且可能因一个应用程序而异。

上面的相同原理也适用于此。不要重新发明轮子，不要实施临时解决方案，并且将所有内容保留在版本控制中。显然，您无法将操作系统检入版本控制中，但是它的配置和脚本可以。

我想肯定地说，管理环境可能是自动化最困难的事情之一。最终目标是能够通过按一下按钮来重新创建完整的环境基准，包括及时地创建不同的版本。为了使它起作用，您绝对必须与非常敏捷的IT环境建立强大的协同作用，这在大多数组织中不一定是这种情况，而且成本很高。在管理环境方面，不同的部门可能有非常不同的理念-必须打破这些孤岛。

结果，许多组织求助于由Citrix或VMWare支持的虚拟环境或诸如AppEngine，Amazon EC2，Rackspace，Heroku，Azure等云环境。您需要能够完全控制部署到的环境。正如我之前所说的，首先要尽可能地实现自动化，朝此方向迈出的小步伐将为我们带来很多好处。我没有任何环境管理经验，但是我听说过有关Puppet之类的系统的好消息。

结论

配置代理位于连续交付的核心。存储所有应用程序和基础结构信息，以便您可以重新创建环境：配置，数据库，DNS区域文件，防火墙配置，补丁程序，已安装的库，扩展名等。自动化过程（我们将在后面的文章中看到）将取决于每个工件，您的应用程序需要按需访问。

在我从事的项目中，我总是经常促进签入到版本控制中，以及经常从版本控制中进行对等更新。它对于解决冲突和繁琐的合并很有帮助。

持续交付的一个警告是反对分支。分支是连续集成的对立面。如果您使用的是Git或Mercurial（其中分支和合并为常态），请建立适用于您的团队的提交和推送策略，您希望拥有一个稳定且更新的主干线，您可以从中部署代码。建议之一，与您的Ops团队会面，以确定如何为您的应用程序正确实施配置管理。这是每个人都应注意的系统方面。如果将键值巴黎用作配置选项，请为属性键使用描述性名称。该名称应非常清楚，简洁地表示配置的用途。在属性文件上使用大量注释以添加更多描述是必要的。看一个PHP安装的php.ini文件，这是一个很好的例子。不要在需要访问它们的地方硬编码属性键，而应使用某种ConfigurationService包装它们，以使此访问变得简单且可测试。

最后，Web系统通常在某种管理控制台中公开应用程序的配置，以供超级用户管理员更改。尽管这听起来像是个好主意，但直到现在我还以为是，但这还不是。除非您可以将该更改写回到版本控制中，否则运行时系统配置不是一个好主意。此外，对属性文件的简单更改可能会破坏或降级整个系统。因此，它应该遵循与更改源代码相同的机制。