我最近从波特兰回来，或者，我在 hashiconf 上发言的地方。我在会议上玩得很开心，还参观了波特兰，品尝了 著名的巫毒甜甜圈。
我在 hashiconf 上的演讲是关于我们在 electric cloud 如何使用 hashicorp 的一些工具——由我们自己的 electricflow 精心策划——在整个组织中创建和共享一个可重复使用的演示库，从开发、质量保证甚至销售。我所说的总体模式是找到业务问题，确定需求，然后找到可行的解决方案。对于我们使用的上述每个工具，我解释了它们如何解决我们当时遇到的业务问题，我们如何获得组织中各个利益相关者的支持，以及我们如何将这些工具配置为整体解决方案的一部分。
hashiconf 很快就会发布我演讲的视频记录（现在，请自行观看 扬声器平台上的幻灯片 ——嵌入在下方）。在这篇文章中，我将稍微解释一下我们如何将 Terraform 用于 基础设施即代码 （使用 chef 或 puppet 可以实现类似的结果。）
使用 terraform 引导 wildfly 集群：
我们使用 terraform 来启动 wildfly 实例，用作我们的演示环境。
域模式下的 Wildfly 集群需要在域和主机控制器之间进行一些配置。我们的模型如下图所示 - 我们部署到域控制器，用户从不同的主机获得服务。
以域模式部署到 Wildfly 集群
terraform 允许我们 编写我们想要的定义 ，将其签入源代码管理并与所有感兴趣的各方共享。 （在 github 上查看我们的代码： https://gist.github.com/nikhilv/74a107af7e44866e3f14 ）
在对 Terraform 文件进行编码后，我们可以看到执行计划的可视化表示。
地形执行计划
在使用 Terraform 之后，我们欣赏了重现基础设施的能力，它允许进行快速实验，同时仍保留可在未来用于其他演示的构建块。
为了记录 Terraform 所做的更改，操作员不应直接使用 Terraform 来控制生产。相反，它需要在一个工具中执行，该工具可以跟踪历史并允许用户接受或拒绝对基础设施提出的更改。
一旦 Terraform 创建了基础设施，我们就使用 electricflow 将应用程序部署到 Wildfly 集群。我在演讲中做出的得到很多回应的陈述之一是要注意你使用用户界面构建你的过程的方式——因为这项工作通常不能重复使用（克隆除外） .例如，terraform 允许您将通常通过 aws ui 输入的大量 aws 配置定义为代码。这使您的配置记录在案，签入源代码管理，并且可重复。同样，为了同样的好处，我们使用我们的 electricflow dsl 将我们的流程定义为代码——这样我们的部署和应用程序流程也在源代码控制中，并且是版本化的和可重用的。此外，它允许我们更快地克隆/扩展（因为我们只需要复制代码，而不是使用 ui）。
您可以阅读更多关于我们如何编排这个难题的其他部分的信息，例如 vagrant 和 docker 。另外，请随时查看我上面和 github 上的代码示例。
感谢 hashiconf 邀请我发言，也感谢这次盛大的会议和这件很棒的夹克！
