一位新手SRE参加HashiCorp Meetup的经历故事

我是寺冈，一名基础设施工程师。
在公司里，我隶属于SRE团队，负责基础设施设计、建设和运维的整个流程。
顺便一提，SRE通常代表“站点可靠性工程”（Site Reliability Engineering），但
因为这意味着“我们关注的是整个服务，而不仅仅是站点”。
，我们称之为“服务可靠性工程”（Service Reliability Engineering），

这次我想聊聊参加HashiCorp Meetup的经历。
HashiCorp的工具套件，这些工具目前在DevOps支持领域可是炙手可热
这次去东京的行程很短，因为活动地点在涩谷Hikarie，我们在那里了解了
从大阪坐新干线过去大概要3个小时，所以路程还挺远的……
我暗暗希望他们下次能在大阪也办一次！

■ 印象要点

• 意大利熏火腿和啤酒是最好的。
• 米切尔·桥本喜欢玩文字游戏（他曾赠送筷子作为礼物，以此来指代 HashiCorp 公司）。
• 大约 80% 的人使用 Terraform。
• 包装商约占40%
• 似乎目前使用 Cousul/Vault/Nomad 的人还不多。
• 我对 Consul Connect（它可以加密服务之间的通信）很感兴趣。
• 我想尝试使用 Sentinel（配置即代码），所以我希望它能开源！

DeNA 为我们提供了意大利熏火腿和啤酒，味道好极了。

我们还收到了一整条意大利熏火腿作为礼物！ pic.twitter.com/gkvdEB20zK

— HashiCorp Japan (@hashicorpjp) 2018年9月12日

我觉得米切尔·桥本的双关语非常搞笑。
更让我印象深刻的是，他真的兑现了承诺，在活动现场分发了筷子。

从技术角度来看，Terraform 的普及率非常惊人。
当被问及“有人用过它吗？”时，几乎每个人都举起了手。

我学习 Packer 才学到一半，但
它是管理机器镜像的最佳实践工具，
我个人认为

我们公司只在少数项目中使用 Terraform/Packer，所以
我认为我们应该先对代码进行模块化和标准化，以创建一个更高效的系统，然后
再开始测试 Consul 在我们尚未实现的工具中的应用。
接下来，我将总结演讲者们的发言内容。

■ HashiCorp 产品：活跃于人工智能和分析平台！

DeNA株式会社系统总部人工智能系统部 松木秀典先生

- 负责人工智能和分析基础设施。-
构建并运营一个基础设施，使人工智能研发工程师能够轻松自由地进行开发。-
使用 HashiCorp 工具解决人工智能和分析基础设施中的挑战。

人工智能基础设施

该人工智能项目由多个小型项目组成，每个项目涉及2-3人。
每个项目都使用AWS和GCP来处理高度敏感的数据和海量数据，
因此需要快速搭建特定平台的基础设施。

解决人工智能基础设施问题

- 使用 Terraform
　- Terraform 用作基础设施配置工具
　- 使用 Terraform 启动实例，并使用 itamae 安装中间件
　- 现在可以使用工具轻松构建实例
　- 通过启动配备 GPU 的实例来构建机器学习基础设施

- 建议使用 Packer
　- 我们正在推进 AI 基础设施的 Docker 化
　- 我们希望使用 Packer 在 AWS/GCP Docker 仓库中管理它
　- 我们还希望用 HCL 编写 Packer（我完全理解了这一点，忍不住点头表示同意……）

分析基础设施

- 使用 fluentd 收集服务日志
- 使用 Hadoop 分析收集到的日志
- 使用 embulk 将结果导入 BigQuery
- 在 Argus Dashboard 中可视化结果
- 升级 Hadoop 很麻烦……
- 即使是验证分析基础架构本身也很困难。

解决分析基础设施问题

我打算用 Vagrant 测试一下分析平台！
但是真的很难……（显然，这还是个遗留问题）

印象

我认为 Terraform 的多提供程序特性非常符合我们的需求。
我们一致同意不使用 Terraform 的配置器（尽管我们用 Ansible 代替了 Itamae）。
我完全同意用 HCL 编写 Packer 的想法。

■ 支持容器基础架构的 HashiCorp 软件

小田智弘先生，首席工程师，技术基础设施团队，技术部，GMO Pepabo公司

棒棒糖！托管云

- 基于容器的PaaS
- 提供运维支持的云服务，类似于面向云的租赁服务器
- 根据容器负载动态扩展
- 不使用Kubernetes或Docker
- 使用名为Oohori/FastContainer/Haconiwa的专有容器环境
- 所有功能均为自主开发（使用Golang开发）

为什么要自行开发和使用？

- 提供低成本的容器环境需要高密度的容器。-
用户管理的容器需要持续安全。-
容器资源和权限需要可配置且主动管理（容器本身会动态更改资源）。-
总之，必须满足这些要求！

总体特征

- OpenStack 和裸机混合环境
- 使用 Packer 创建的最小化镜像，所有角色共享
- 使用 Knife-Zero 而非 Terraform Provisioner -
开发环境为 Vagrant
- 由于频繁的重大规范变更和众多无状态角色，策略上放弃 Immutable Infra

Terraform

- 我们尽可能地复用模块。-
tfstate 仍然托管在 S3 中
。- 生产环境和预发布环境使用工作区
。- 设置生命周期对于预防事故至关重要。-
fmt 用于持续集成 (CI) 中。

领事

- 主要功能是服务发现。-
根据是外部监控还是服务监控，角色通过 Mackerel 进行划分。-
名称解析使用 Consul 的内部 DNS 和 Unbound。-
它还用作 Vault 的存储后端
。- 所有节点都安装了 ConsulAgent/Prometheus 的 Consul/node/blackbox exporter。-
通过在跳转服务器上使用 Consul 进行名称解析，可以方便地实现多阶段 SSH 连接。-
可以使用 Consul DNS 对上游代理进行轮询。

金库

- 使用 PKI 和 Teamsit 密钥
- 数据库中存储的所有敏感信息均使用 Vault 加密
- 已发布的敏感信息通过 Chef 分发
- 延长 TTL 时使用令牌 - 令牌
在最大租约 TTL 截止时间后过期

PKI RootCA 分发问题

如何建立与 Vault 服务器的 TLS 连接
：• 使用 Consul 作为存储会自动为活动 Vault 配置 vault.service.consul。
• Vault 配置为证书颁发机构，您需要手动颁发服务器证书。
• Vault 重启后将自动密封。

使用控制台模板 2

- 使用 SIGHUP 信号重新加载 Vault 中的服务器证书
- SIGHUP 不会进行密封
- 也可用于审计日志中的日志轮换
- Vault 颁发的根 CA 通过 Chef 分发

应用程序令牌分发问题

应用程序使用批准请求向 Vault 进行身份验证。
身份验证成功后，系统会颁发一个具有指定生存时间 (TTL) 的令牌
。应用程序使用该令牌与 Vault 通信。
应用程序无需拥有批准请求的 role_id 和 secret_id。
令牌是在应用程序进程之外颁发的。

应用程序令牌分发问题的解决方案

- 部署应用程序时，执行命令以进行身份​​验证批准
。- 该命令会 POST 请求身份验证密码 secret_id 的 TTL 扩展值。-
然后，执行身份验证并获取令牌。-
将获取的令牌放置在应用程序可以访问的路径中。

Vault Token 过期并引发了问题

- Approle 的 secret_id 设置为自定义 secret_id 以便续订
。- 为自定义 secret_id 设置的 token 通过 auth/token 颁发
。- 每个挂载的 secret 都有一个名为 max-lease-ttl 的设置，此外，整个系统还有一个最大 TTL。-
如果这两个设置都未设置，则上限为 32 天，即系统的最大 TTL。-
当 token 过期时，audit.log 中经常出现 403 错误。-
Vault 服务器上的 Consul 检查中添加了对 audit.log 的监控。-
检测到的问题会通过 Consul Alert 通知到 Slack。

印象

- 他们不用 Kubernetes 或 Docker 就开发了自己的解决方案，这令人印象深刻。-
许多公司不使用 Terraform 的 Provisioner，而是使用其他配置管理工具。-
使用 tfstate 定义后端并用 S3 管理是最稳定的方法。-
我通常不使用生命周期描述，所以我意识到我需要学习一下。-
我目前也在做一个项目，涉及从跳板机进行多阶段 SSH 连接，所以我想尝试使用 Consul。-
说实话，我对 Vault 还不太了解……我需要更深入地学习一下。

■Terraform/packer 支持 applibot 的 DevOps

Applibot公司（Cyber​​Agent集团）
规划开发部系统运营工程师

- 每个应用都由一个独立的公司负责组建团队。-
只有两位系统运维人员（负责服务器环境的搭建人员）！
- 系统运维人员经常与应用团队的服务器工程师合作。-
一个关于我们如何利用 Terraform/Packer 解决过去问题的案例。

案例 1：图像创建

- 使用 RUNDECK/Ansible/Packer
- 与 Ansible 配合创建机器镜像
- 优势：允许您对镜像创建过程进行模板化处理

之前：
　从 AMI 启动 EC2 实例
　，使用 Ansible 应用配置更改
　，并删除从中获取镜像的服务器
　——所有这些操作都是手动完成的。

- 在执行
　Packer 构建命令后：一键

案例 02 荷载试验施工

- 使用 Terraform/Hubot
- SYSOP 负责设置、修改和审查负载测试环境。

- 基础设施搭建
　：- 最终目标是搭建一个与生产环境等效的环境
　- 在测试时创建
　- 每次测试都需创建，因为维持与生产环境相同的规模成本很高
　- 即使在测试期间，不使用时也应保持较小的规模 -
　用于负载测试的服务器
　　- 使用 JMeter，网络和服务器使用单独的账户。-
　　主从配置。从服务器使用自动扩展进行扩展
　　- 每次测试都创建，不使用时删除
　- 各种监控工具
　　- Grafana/Prometheus/Kibana + Elasticsearch

之前：
　・手动使用 awscli 管理所有托管实例
　・使用脚本调整启动顺序
　・创建密钥配方
　・每天早晚由系统运维人员进行扩容和缩容

- 之后
　：所有组件现在都基于 Terraform
　。现有资源通过 `Terraform import` 进行管理
　。如果出现一致性问题，则直接修改 `tfstate`
　。启动管理集中化。
　可以通过查看 Terraform 代码来理解配置
　。现在可以使用 `Terraform apply` 完成创建和扩展
　。配置顺序通过 `depend_on` 指定。
　基础设施扩展通过切换变量来实现
　。现在所有操作都可以完全通过 Slack 通知完成。

案例 3：构建新环境

・使用 Terraform/GitLab

操作前：
　・封禁根账户
　・合并计费设置
　・创建 IAM 用户、组和交换机
　・创建用于 CloudTrail/日志的 S3 存储桶
　・网络设置并打开监控端口

- 完成后
　- 现在可以管理帐户设置
　- 根帐户已密封
　- 合并计费设置
　- 为 Terraform 创建了 IAM 用户
　- Terraform 执行正常
　- 也可以使用合并请求管理配置更改

创建日常任务模板非常重要！！

印象

使用 Packer + Ansible 创建机器镜像非常方便
。您可以使用 Packer 创建机器镜像，同时使用 Ansible 管理要执行的命令配置。
除了 Ansible，Packer 还可以执行 shell 脚本
。我们还使用 Terraform 构建负载测试环境，所以这很有帮助。
我们还没有使用 Hubot 进行聊天通知，所以我想尝试一下。
构建新环境所需的所有流程似乎都模块化了，这非常有用。

■tfnotify - 在 GitHub 上美观地展示 Terraform 执行计划

b4b4r07，Mercari, Inc. 软件工程师

tfnotify是什么？

- 一个基于 Go 的 CLI 工具
，用于解析 Terraform 的执行结果并将通知发送给指定的收件人。-
可通过管道使用，例如 `terraform apply | tfnotify apply`。

为什么有必要这样做？

- 我们在微服务领域使用 Terraform。-
从所有权角度来看，代码合并审查应由各个微服务团队完成，但在某些情况下，我们也希望平台团队进行审查。-
我们希望平台/微服务团队理解 IaC 的重要性，使用 Terraform 编写代码，并养成每次都审查执行计划的习惯。-
我们希望避免访问 CI 页面的麻烦（我们希望在 GitHub 上快速查看）。

Mercari 上的 Hashicorp 工具

- 共有超过 70 个微服务
。- 所有微服务及其平台的底层架构均使用 Terraform 构建。-
鼓励开发者实践
基础设施即代码 (IaC)。- 共有 140 个 tfstate。-
所有 Terraform 代码都集中在一个中央代码库中进行管理。

存储库配置

- 为每个微服务创建单独的目录
- 为每个服务创建单独的 tfstate 文件
- 为每个资源创建单独的文件
- 使用 CODEOWNERS 委托权限

授权

- GitHub 功能
- 允许在代码所有者列表中列出的人员批准之前禁用合并
- 防止未经授权的更改

实现 tfnotify

- 使用 io.TeeReader
- Terraform 执行结果使用自定义解析器进行结构化
- 可以使用 Go 模板编写 POST 消息
- 配置以 YAML 格式存储

印象

- 我一直在思考如何在中央仓库中使用 Terraform 并管理 Git 代码，所以这篇文章很有帮助。-
如果 tfnotify 支持 GitLab CI 和 ChatWorks 就更好了。-
让开发者实践 IaC 很重要，每次执行 Terraform 时仔细检查执行计划也很重要。-
我想尝试使用 GitHub 的 CODEOWNERS 功能（我想先迁移到 GitHub……）。

关于dwango对HashiCorp开源软件的使用

铃木英吾先生，Dwango株式会社，第二服务开发部，Dwango云服务部，
咨询科，第二产品开发部，第一科

dwango的基础设施

VMware vSphere
、AWS
、裸机
以及一些 Azure/OpenStack 应用程序。

dwango 的 HashiCorp 工具

- 用于创建 Packer
　和 Vagrant 镜像。-
　由于 AWS 环境数量的增加，也用于创建 AMI。-
　
Consul
　用作
　　。- 在 MySQL 服务器宕机时重写应用程序配置文件。-
　用作键值存储 (KVS) 和健康检查。-
　用作 Ansible playbook 的动态清单
　
Terraform
　用于使用
　　。- 用于 Nico Nico Survey、friends.nico、NicoNare 和 N-Yobiko 的部分功能。

使用 Terraform 进行持续集成（使用的工具）

・github
・Jenkins
・Terraform
・tfenv

使用 Terraform 进行 CI（流程）

1. 提交拉取请求。2
. 在 Jenkins 中，执行 plan -> apply -> 销毁 pr_test 环境。3
. 如果步骤 2 通过，则执行 plan -> apply 到 sandbox 环境。4
. 如果所有步骤都通过，则合并更改。

Terraform 实现持续集成 (CI) 的好处

- 您可以在 GitHub 上查看 apply 命令是否成功
。- 环境配置为 dev/prod，因此您可以提前确认 apply 命令可以安全执行。-
tfenv 可以轻松检查 Terraform 本身何时更新。

使用 Terraform 进行 CD

- 我们希望在持续集成 (CI) 测试通过后，自动部署到开发环境等。-
我们已使用 Jenkins 来确保部署的安全性。-
现在，无论由谁执行部署任务，都可以顺利完成部署。-
结果会通过 Slack 通知，方便查看。

印象

Packer 仍然是创建 AMI 最便捷的工具。
我们公司使用 Ansible，所以我想尝试使用 Consul 作为动态清单。
切换 tfenv 版本很方便。Terraform
有时即使部署计划通过也无法执行，因此部署到 pr_test 环境是一个不错的选择。Jenkins
仍然是持续部署 (CD) 的最佳选择。将其作为作业运行比直接执行命令更简单可靠。

以上是概要，主要以要点形式呈现。
我们公司也希望积极使用 HashiCorp 的工具来实现基础设施即代码 (IaC)！