fluent瞬态_瞬态环境

在经济学中，稀缺的根本问题“具有人类[有] ...无限的希望和资源有限的世界需求”（见相关主题 ）。 当资源稀缺时，人们就会争夺资源。 当人们可以访问传统软件项目上的环境时，对资源的竞争显而易见。

优点在于，由于硬件商品化，虚​​拟化和云计算，当在项目上使用适当的模式和实践（例如临时环境）时，这种竞争可以大大减少。 瞬态环境是寿命很短的环境，经常会终止。 需要明确的是，稀缺性永远不会消失，但是您会体验到无限容量的幻想 。 应用瞬态环境模式时，您会开始忘记它甚至是一种幻想。

关于本系列

开发人员可以从操作中学到很多，操作可以从开发人员中学到很多。 本系列文章致力于探索将操作思维方式应用于开发（反之亦然）的实际用途，以及将软件产品视为可以以比以往任何时候都更高的敏捷性和频率交付的整体实体。

有时，您会听到其他名称所指的这些类型的环境，包括短暂的 ， 暂时的 ， 临时的和一次性的 。 所有这些本质上是同一回事–非生产环境的寿命尽可能短。 最近，我的公司一直建议它们持续不超过72小时-这是高端的。

动机

当团队拥有固定的实例，其他任何人都无法更改时，就会发生软件开发中最具挑战性的问题之一。 通常，发生这种情况是因为配置环境需要几天，几周或几个月的时间。 这是一种反模式，因为没有人花时间编写环境脚本。 因此，环境是稀缺资源，因此对它们的竞争非常激烈。 当确实存在环境租赁政策时，通常会忽略它们，或者将租赁期限延长多次。

什么是环境？

环境不仅仅是（物理或虚拟）计算机的别称。 环境是系统资源的集合，包括但不限于实例（物理，虚拟或机器抽象），网络配置，软件服务器和配置（针对每个实例），负载均衡器以及其他资源。视为逻辑单元。 您可以根据模板或其他配置实例化环境。

我见过的大多数项目都没有环境租赁政策，或者它们定义得很松散，经常被违反。 对于确实具有租赁策略的环境，环境需要在创建环境后手动安装工具，数据和配置。 这使得每个环境都是唯一的 ，因此更难管理，因为可能会在大型企业项目中配置数百个环境。 在这种情况下，没有简单的方法可以返回到环境基准。 而且，没有团队成员知道如何将其恢复到该基线状态。 结果，团队成员不愿意终止（甚至修改）这些环境。 这种反模式使创建和终止环境的成本高得惊人。

特征

对于瞬态环境，除了生产之外，所有环境都是短暂的（尽管也有使生产环境短暂的有效方法）。 尽管这可能会因项目而异，但启发式方法是，这些环境仅存在足够的时间才能通过一套自动化和探索性测试运行。 临时环境的关键先决条件是对它们进行脚本编写 ， 测试和版本控制 。 理想情况下，您应该使用基础架构自动化工具，例如我在“ 敏捷DevOps：基础架构自动化 ”中讨论的工具。

构成瞬态环境的关键功能是：

• 脚本化环境 ：它们是完全脚本化，版本化和测试的。
• 自助环境 ：团队中的任何授权人员都可以启动新环境。
• 自动终止 ：根据团队策略自动终止环境。 团队成员无权覆盖该策略。

拥有完全脚本化的环境后，您可以使授权的团队成员以自助方式获取它。 自由地根据需要简单地启动和终止环境是责任。 通过定义终止策略并通过定期终止环境的自动化过程来实施这些策略，可以加强这种责任。 （我将在本系列的后续文章中介绍测试驱动的基础结构和版本控制）。

好处

参与其中

developerWorks 敏捷转换提供新闻，讨论和培训，以帮助您和您的组织在敏捷开发原则上建立基础。

通过定义瞬态环境策略并自动在项目中执行这些策略，您可以减少独特环境的扩散，支持自助服务部署，提高环境实例化的自动化，朝着将环境转变为商品的文化，进行测试隔离，并大大减少了针对特定环境问题的故障排除量。 一些主要好处是：

• 减少环境依赖性 ：通过提供随意启动和终止它们的功能，减少团队对任何一种特定环境的依赖性。
• 更好地利用资源 ：通过终止不再使用的环境，可以为其他人释放容量。
• 知识转移 ：当团队成员知道他们的环境将在特定时间终止时，自动化将成为有关如何配置环境的机构知识的唯一解决方案。

这个怎么运作

关于瞬态环境的好处是，一旦对环境进行了完整的脚本编写，版本控制和测试，这是一种非常简单的实施模式。 此时，您需要执行三个主要任务：

• 创建团队策略 ：与团队成员协作，根据项目要求确定团队策略。 我建议积极开始并定期将这些环境的运行时间减少到大约72小时。
• 自动终止环境 ：编写一个脚本来终止超出团队租赁策略的所有环境。
• 计划环境终止 ：计划要定期运行的进程，该进程执行环境终止脚本。

将团队策略基于运行所有必需测试所需的时间。

要计划终止环境，可以使用cron的计划程序或（如果使用Java，则是Quartz）开始（请参阅参考资料 ）。 您也可以使用Continuous Integration服务器提供的调度程序来每天定期运行作业。 此示例显示了一个简单的cron表达式，该表达式每天凌晨2:15运行一次脚本

0 15 02 * * /usr/bin/delete_envs.sh

下一个示例使用Amazon Web Services（AWS）CloudFormation提供的命令行界面终止CloudFormation堆栈定义的环境：

/opt/aws/apitools/cfn/bin/cfn-delete-stack --access-key-id $AWS_ACCESS_KEY \
--secret-key $AWS_SECRET_ACCESS_KEY --stack-name $current_stack_name --force

可以将此类脚本扩展为在环境目录中循环并终止所有关联的资源。

通过定义积极的团队策略，安排流程并自动终止环境，您的团队可以主动管理资源，并减少项目依赖的环境存在数周或数月的机会。

故障排除

通常在大多数项目中如何进行环境故障排除？ 以我的经验，这是确定更改内容，更改人员以及更改原因的痛苦尝试。 通常，有几个人调查问题以确定适当的补救措施。 由于每个环境都是唯一的，因此通常会重复出现该问题，因为在运行数周或数月时会对它进行了独特的修改。

另外，通过基于脚本，版本和测试环境的瞬态环境策略，您可以使环境进入已知状态。 为此，您启动一​​个新环境并应用更改以确定其效果。 然后，编写自动化测试和脚本，然后对更改进行版本控制。 因为有效的变更管理已经到位，所以您总是可以回到已知状态进行变更，而不用浪费数小时或数天来确定在由无数用户修改的动态环境中进行了哪些变更。 这是拥有规范环境的本质。

短暂停留

在本文中，您了解了敏捷的DevOps环境是尽可能短的-最少几个小时又几天。 通过定义策略并安排环境的自动终止，您可以减少对有限数量的唯一环境的依赖，更好地利用资源，并鼓励自动化，以便可以根据需要启动和终止环境。

在下一期敏捷DevOps中 ，您将学习如何创建一个不断失败的环境，这是自相矛盾的，目的是防止失败。 在其中，我将介绍由Netflix技术团队开发的工具Chaos Monkey，该工具有意且随机但有规律地终止了Netflix生产基础设施中的实例，以确保系统在发生故障时能够继续运行。

---

翻译自: https://www.ibm.com/developerworks/java/library/a-devops3/index.html