terraform_使用Terraform通过代码配置AppDynamics

terraform

As easy as it is to change configuration in User Interfaces maintaining this over a long time becomes a hassle. This is especially true if you are looking after configuration for multiple environments and applications. In this article, we look at a new Terraform provider for AppDynamics to get around this issue using configuration as code.

轻松更改用户界面中的配置很长一段时间，这很麻烦。 如果您要为多个环境和应用程序进行配置，则尤其如此。 在本文中，我们将为AppDynamics寻找一个新的Terraform提供程序，以使用配置作为代码来解决此问题。

为什么配置为代码 (Why Configuration as Code)

The ‘as code’ practice has been thrown around a lot recently. You may recognise it in infrastructure as code which is often used to build applications on AWS. Ther are various tools used for this such as Terraform, CDK, CloudFormation and Puppet to name a few. We will be using Terraform later on, an introduction to this can be found here.

最近，“作为代码”的实践被广泛使用。 您可能在基础架构中将其识别为通常用于在AWS上构建应用程序的代码。 这是用于此目的的各种工具，例如Terraform，CDK，CloudFormation和Puppet等。 稍后我们将使用Terraform，可以在此处找到对此的介绍。

The alternative to this practice is to manually create and change things. This could be running commands on servers or changing things in user interfaces (UIs). This makes reproducing things hard as you have to remember and manually apply the changes.

这种做法的替代方法是手动创建和更改事物。 这可能是在服务器上运行命令或更改用户界面(UI)中的内容。 由于您必须记住并手动应用更改，因此很难重现内容。

By defining our config as code we get the benefit of being able to reuse it. If we apply good programming techniques we can modularise it and use it in many places. Some examples of this are using the same configuration in pre-production and production environments and sharing common configuration between similar applications.

通过将配置定义为代码，我们可以重用它。 如果我们应用良好的编程技术，则可以将其模块化并在许多地方使用。 这样的一些示例是在预生产和生产环境中使用相同的配置，并在相似的应用程序之间共享通用配置。

Configuration as code allows us to keep our configuration close to the related codebase. This makes it easy to find and edit but also allows people to easily view the configuration without having to log into third-party applications. The config can also be checked into version control allowing it to change with the application and also have audit and collaboration tools. If your company is SOX compliant this could be used as a control.

配置为代码可以使我们的配置保持在相关的代码库附近。 这使查找和编辑变得容易，但也使人们可以轻松查看配置，而不必登录第三方应用程序。 还可以将配置检入版本控制中，以使其随应用程序进行更改，并且还具有审核和协作工具。 如果您的公司符合SOX规范，则可以将其用作控件。

什么是AppDynamics (What is AppDynamics)

AppDynamics (AppD) is an Application Performance Monitoring (APM) tool. It instruments your applications so you can see how the internals are working. This in includes database queries, HTTP requests and more. It provides you with various metrics such as latency, requests and errors to give you confidence things are working as expected. Alerts can be set up to notify you when things are not working as expected for someone to intervene and fix.

AppDynamics (AppD)是一个应用程序性能监视(APM)工具。 它会对您的应用程序进行检测，以便您可以查看内部工作方式。 其中包括数据库查询，HTTP请求等。 它为您提供各种指标，例如延迟，请求和错误，以使您确信事情按预期进行。 可以设置警报，以在事情无法按预期进行时通知您，以便某人进行干预和修复。

One of AppDynamics key selling points is autoconfiguration. In reality, teams generally need to manually configure their applications, especially if it is a rest application with ids in the path. To configure applications teams would have to use the UI provided by AppD and have to make this configuration in every environment.

AppDynamics的主要卖点之一是自动配置。 实际上，团队通常需要手动配置他们的应用程序，特别是如果它是路径中带有id的其余应用程序。 要配置应用程序团队，必须使用AppD提供的UI，并且必须在每个环境中进行此配置。

给我看看代码！ (Show me the code!)

To configure AppDyanmics using code, a Terraform AppDynamics provider has been made. This can be found in the Terraform community registry and GitHub. Below is an example Terraform file which configures a restful endpoint with transactions and sets up an alert. The example makes use of the new provider syntax in version 0.13 allowing easy integration of community providers. Documentation for the AppDynamics provider can be found here.

要使用代码配置AppDyanmics，已制作了Terraform AppDynamics提供程序。 可以在Terraform社区注册表和GitHub中找到 。 下面是一个示例Terraform文件，该文件使用事务配置一个宁静的端点并设置警报。 该示例使用版本0.13中的新提供程序语法，可以轻松集成社区提供程序。 可在此处找到AppDynamics提供程序的文档。

That's a fair bit of code, lets break it down. The first 27 lines are defining variables so we can reuse them later on. Don’t worry all the values in this file are fake. If you were running this in a pipeline the values for the variables would be passed in. See the documentation for assigning variables for more information.

那是一段相当不错的代码，让我们分解一下。 前27行定义了变量，因此我们以后可以重用它们。 不用担心此文件中的所有值都是伪造的。 如果在管道中运行此变量，则将传递变量的值。有关更多信息，请参见有关分配变量的文档 。

The first main configuration block starts at line 29, this creates a transaction detection rule which tells AppDynamics how to group requests together. In this example, we are using regex to group the restful user endpoint together which ends with an id. By default, AppD would create a new transaction for each user id.

第一个主要配置块从第29行开始，这将创建一个事务检测规则，该规则告诉AppDynamics如何将请求分组在一起。 在此示例中，我们使用正则表达式将宁静的用户端点分组在一起，并以id结尾。 默认情况下，AppD将为每个用户ID创建一个新事务。

The next block starting at line 42 creates a health rule. This rule checks all business transactions in an application and compares them to a baseline. Health rules are used to define what is healthy for an application.

从第42行开始的下一个块将创建健康规则。 此规则检查应用程序中的所有业务交易，并将它们与基准进行比较。 健康规则用于定义什么对应用程序而言是健康的。

An action is defined starting at line 56, when an action is triggered it performs something. In this case, it sends an email to a list of addresses.

从第56行开始定义一个动作，当触发一个动作时，它将执行某些操作。 在这种情况下，它将向地址列表发送电子邮件。

Lastly starting at line 65 a policy is defined. This connects health rules and actions together. When the health rule changes the action is triggered. Notice how we can reference attributes from the health rule and action so if they change the policy is automatically updated. In this example, the policy is looking at all the health rules in the application and triggering the previously set up action. Due to how the AppDynamics API works for an email action we have to use the list of emails as the action name.

最后，从第65行开始定义策略。 这将健康规则和行动联系在一起。 当健康规则更改时，将触发操作。 请注意，我们如何从运行状况规则和操作中引用属性，因此，如果它们更改，则策略将自动更新。 在此示例中，策略正在查看应用程序中的所有运行状况规则，并触发先前设置的操作。 由于AppDynamics API对于电子邮件操作的工作方式，我们必须使用电子邮件列表作为操作名称。

未来配置 (Future Config)

The terraform provider is currently limited to single metric health rules. This is mainly to reduce the complexity of the initial release but also as having multiple metrics in one rule could be an anti-pattern. Should they not be separate rules?

terraform提供程序当前仅限于单个度量标准运行状况规则。 这主要是为了降低初始发行版的复杂性，而且还因为一条规则中包含多个度量标准可能是一种反模式。 它们不应该是单独的规则吗？

There are some resources which have not been implemented yet such as Scopes and Action Suppression. These can still be created in the UI until they are included in a future release.

有一些资源尚未实现，例如范围和行动抑制。 在将来的版本中包含它们之前，仍然可以在UI中创建它们。

If you do need a feature which is missing in the provider please raise an issue on GitHub or vote if one already exists. Issues with more users will be prioritised and as with all good open-source software, pull requests are welcome.

如果确实需要提供程序中缺少的一项功能，请在GitHub上提出问题，或投票(如果已存在)。 与更多用户相关的问题将得到优先处理，并且与所有优秀的开源软件一样，欢迎提出请求。

I hope this Terraform provider can help you keep your engineering practices intact by providing a config as code solution for AppDynamics. Please feel free to raise a GitHub issue if you have any issues or suggestions.

我希望这个Terraform提供者可以通过为AppDynamics提供配置作为代码解决方案来帮助您保持工程实践。 如果您有任何问题或建议，请随时提出GitHub问题 。

翻译自: https://itnext.io/configuring-appdynamics-through-code-using-terraform-f499068b5d02

terraform