Hiyoko SRE 参加 HashiCorp Meetup 的故事

我叫寺冈，是一名基础设施工程师。
我隶属于公司的SRE团队，负责基础设施设计、建设和运维的各个方面。
虽然SRE通常代表“站点可靠性工程”，但

，我们称之为“服务可靠性工程”，因为我们关注的是整个服务，而不仅仅是站点本身

这次我想和大家分享一下我参加 HashiCorp Meetup 的经历。

地点在东京涩谷的 Hikarie，我们在那里了解了
备受瞩目的 HashiCorp DevOps 工具，从大阪坐新干线过去要三个小时，真的挺远的……
我其实很期待下次在大阪举办的活动！

■ 印象要点

• 意大利熏火腿和啤酒是最好的。
• 米切尔·桥本喜欢玩文字游戏（他曾赠送筷子作为礼物，以此来指代 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
・通过 ArgusDashboard 进行可视化
・Hadoop 版本升级很困难……
・甚至连分析基础设施的验证都困难重重

解决分析基础设施问题

・正在用 Vagrant 测试分析基础设施！
・但是还是很难……（显然，这仍然是一个未完成的项目）

印象

・我认为多提供商的 Terraform 非常符合我们的需求。
・我们都同意不使用 Terraform 配置器（尽管我们公司使用的是 Ansible，而不是 Itamae）。
・我完全同意想要用 HCL 编写 Packer 的想法。

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

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

棒棒糖！托管云

・基于容器的PaaS
・基于云的自营租赁服务器
・根据容器负载动态扩展
・未使用k8s或Docker
・使用名为Oohori/FastContainer/Haconiwa的专有容器环境
・全部自主开发（使用golang开发）

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

- 高密度容器是提供低成本容器环境的必要条件。-
用户管理的容器需要持续保持安全。-
容器资源和权限需要灵活可配置且处于活动状态（容器本身会动态更改资源）。-
简而言之，这些都是满足要求的必要条件！

总体特征

・OpenStack 和裸机混合环境
・使用 Packer 创建的镜像数量尽可能少，并供所有角色通用
・使用 Knife-Zero 代替 Terraform Provisioner
・开发环境为 Vagrant
・由于频繁的重大规范变更和大量的无状态角色，放弃使用不可变基础设施

Terraform

・我们尽可能地提高模块的复用率
。・tfstate 存储在 S3 中。
・工作区用于生产环境和预发布环境。
・生命周期设置对于防止意外发生至关重要。
・我们尝试在持续集成 (CI) 中使用 fmt。

领事

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

金库

・使用 PKI 和 Teamsit 密钥
・数据库中存储的所有机密信息均使用 Vault 加密
・已发布的机密信息通过 Chef 分发
・延长 TTL 时使用令牌
・在最大租约 TTL 到期日过期

PKI RootCA 分发问题

通过 TLS 连接到 Vault 服务器时需要注意以下事项
：・使用 Consul 作为存储时，vault.service.consul 会自动为当前活动的 Vault 配置。
・Vault 配置为证书颁发机构，服务器证书由用户颁发。
・Vault 重启后会被密封。

使用控制台模板 2

・使用 SIGHUP 信号将服务器证书重新加载到证书库
・SIGHUP 不会进行密封
・也可用于审计日志的日志轮换
・由证书库颁发的根 CA 由 Chef 分发

应用程序令牌分发问题

・approle 是用于向 Vault 进行身份验证的应用程序。
・身份验证成功后，系统会颁发一个具有指定 TTL 的令牌。
・应用程序使用令牌与 Vault 通信。
・应用程序无需知道 approle 的 role_id 和 secret_id。
・令牌是在应用程序进程之外颁发的。

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

・部署应用程序时，执行 approle auth 命令
。・该命令会 POST 请求 secret_id 的 TTL 扩展名，即身份验证密码。
・然后执行身份验证并获取令牌。
・将获取的令牌放置在应用程序可以读取的路径中。

Vault Token 过期并引发了问题

・设置为自定义 secret_id 以续订 Approle 的 secret_id
・使用 auth/token 颁发设置为自定义 secret_id 的令牌
・每个挂载的 secret 都有一个名为 max-lease-ttl 的设置，整个系统也有一个最大 TTL 值
・如果两者都未设置，则上限为系统最大 TTL 值 32 天
・令牌过期时，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
・系统管理员构建、更改配置并审查负载测试环境

・基础设施准备
・最终，搭建一个与生产环境等效的环境
・在测试时创建
・维护与生产环境相同规模的环境成本很高，因此每次测试都单独创建一个
・即使在测试期间，不使用时也要保持环境规模较小
用于施加负载的服务器
・使用 Jmeter，独立的网络和账户。
・主从配置。从节点使用自动伸缩功能进行扩展。
・每次测试都单独创建一个，不使用时删除。
・各种监控工具
・Grafana/Prometheus/Kibana+Elasticsearch

之前
：对托管实例执行 awscli 命令
。使用脚本调整启动顺序
。关键就此完成
。系统管理员每天早晚处理实例的扩展和收缩。

・之后
・所有组件都已转换为 Terraform
・现有资源使用 `terraform import` 进行处理
・如有任何一致性问题，可直接修改 `tfstate`
・启动管理可以整合
・可以通过查看 Terraform 代码来理解配置
・创建和扩展都可以使用 `terraform apply` 执行
・配置顺序由 `depends_on` 指定
・基础设施扩展通过切换变量来实现
・现在只需 Slack 通知即可完成所有操作

案例 3：构建新环境

・使用 Terraform/GitLab

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

・之后
・现在您可以管理帐户本身的设置
・密封根帐户
・配置合并账单
・为 Terraform 创建 IAM 用户
・只需运行 Terraform 即可
・也可以使用 MergeRequest 管理配置更改

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

印象

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

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

b4b4r07，Mercari, Inc. 软件工程师

tfnotify是什么？

・一个用 Go 语言编写的命令行工具
・解析 Terraform 执行结果并通知目标地址
・通过管道命令 `terraform apply | tfnotify apply` 使用

为什么有必要这样做？

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

Mercari 上的 Hashicorp 工具

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

存储库配置

・每个微服务使用单独的目录
・每个服务使用单独的 tfstate 文件
・每个资源使用单独的文件
・通过代码所有者委托权限

授权

・GitHub 功能
・必须经 CODEOWNERS 列表中列出的人员批准才能合并代码
・未经许可不得进行更改

实现 tfnotify

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

印象

我之前在一个中央仓库里管理 Terraform，正在琢磨怎么用 Git 管理代码，所以这篇文章很有帮助。
如果 tfnotify 能支持 GitLab CI 和 Chatwork 就更好了。
对开发者来说，实践基础设施即代码 (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
和 AWS 环境
・被 Niconico Surveys、friends.nico、Niconare 和 N Preparatory School 的部分成员使用

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

・github
・Jenkins
・Terraform
・tfenv

使用 Terraform 进行 CI（流程）

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

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

・您可以在 GitHub 上查看应用是否成功或失败
。・环境配置为开发/生产环境，因此您可以提前检查应用是否可以安全执行。
・使用 tfenv，您可以轻松检查 Terraform 本身的升级情况。

使用 Terraform 进行 CD

・持续集成测试通过后，我们希望自动部署到开发环境等。
・我们已在 Jenkins 中创建了一个任务来确保安全
。・现在无论谁在执行部署任务，都可以顺利完成部署。
・结果会通过 Slack 通知，方便检查。

印象

・Packer 绝对是创建 AMI 的最佳工具。
・我们公司使用 Ansible，所以想用 Consul 作为动态清单。
・切换 tfenv 版本很方便。
・即使部署计划通过，Terraform 有时也会在 apply 时失败，所以我认为部署到 pr_test 环境是个不错的选择。
・对于持续交付 (CD) 来说，Jenkins 是最佳选择。创建作业比直接执行命令更简单可靠。

……以上是概要，主要以要点形式呈现。
我们也希望积极使用 HashiCorp 工具在我们公司实现 IaC！