Hiyoko SRE 参加 HashiCorp Meetup 的故事

我叫寺冈，是一名基础设施工程师。
在公司内部，我属于SRE团队，负责基础设施的设计、建设和运营。
顺便说一句，SRE 一般代表“站点可靠性工程”，但

，我们将其称为“服务可靠性工程”，因为“我们着眼于整个服务，而不仅仅是站点”。

这次我要谈谈我参加 HashiCorp 的 Meetup 的事情。

这是一次短暂的旅行，因为地点是东京的 Shibuya Hikarie，
有关 HashiCorp 工具是当前支持 DevOps 的热门话题从大阪乘坐新干线大约需要3个小时，所以还是比较远的。 。 。
我们期待下一次在大阪的活动！

■ 印象要点

• 生火腿和啤酒最好吃
• Mitchell Hashimoto先生喜欢双关语（他给他筷子时说“HashiCorp”）
• 大约 80% 的人使用 Terraform
• 包装机约40%
• 似乎很少有人还在使用 Cousul/vault/nomad。
• 我对 Consul Connect 感兴趣（服务之间的通信可以加密）
• 我想使用sentinel（配置即代码），所以我希望它作为OSS发布！

DeNA给我们提供了火腿和啤酒，非常美味。

我们还收到了生火腿原木！ pic.twitter.com/gkvdEB20zK

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

米切尔桥本关于双关语的故事很有趣。
我来这里是因为他们在会场分发筷子来兑现他们的诺言。

在技​​术方面，Terraform 的受欢迎程度是巨大的。
有人用过吗？对于这个问题，大多数人都举手回答。

Packer终于到一半了吗？也就是说
，我个人认为它是管理机器映像的最佳实践工具，因此
您应该能够使用它。

在我们公司，我们只在一些项目中使用Terraform/Packer，因此我们需要
首先通过对代码进行模块化和标准化来创建一个系统，然后
针对尚未引入的工具开始验证Consul的实现。 。 。我想。
所以我会写一下演讲者的内容。

■活跃于AI&分析平台！ HashiCorp产品

DeNA Co., Ltd. 系统部 AI 系统部松木秀则先生

- 负责人工智能基础设施和分析基础设施
- 构建/运营人工智能研发工程师可以轻松自由开发的基础设施。
・使用 HashiCorp 工具解决人工智能和分析基础设施问题

人工智能基础设施

AI项目包括多个2到3人的小型项目。
每个平台都使用AWS和GCP来处理高度机密的数据和海量数据，因此
需要快速为每个平台准备基础设施。

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

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

・Packer 的使用（提案）
・我们正在推进 AI 基础设施的 Docker 化
・我们希望能够使用 Packer 在 AWS/GCP Docker 存储库中管理它
・我们还想在 HCL 中编写 Packer（我发现自己点头，因为这太明显了））

分析基础设施

・使用 fluidd 收集服务日志
・使用 hadoop 分析收集的日志
・使用 embulk 将结果放入 BigQuery
・从 ArgusDashboard 进行可视化
・升级 Hadoop 很困难。 。 。
・连分析平台的验证都很难。

解决分析基础设施问题

・尝试使用 Vagrant 验证分析平台！
・但是还是很难。 。 。 （好像还有剩余作业）

印象数

・我认为 Terraform 作为一个多提供商非常符合要求。
・我们都同意不使用Terraform的provisioner（虽然我们使用ansible，而不是itamae）
・Packer也同意我们想用HCL来编写

■支持容器基础设施的HashiCorp软件

Tomoo Oda，GMO Pepabo, Inc. 技术部技术基础设施团队首席工程师

棒棒糖！什么是托管云？

・基于容器的 PaaS
・可运行的基于云的租赁服务器
・根据容器负载动态扩展
・不使用 K8S 或 Docker
・使用称为 Oohori/FastContainer/Haconiwa 的独特容器环境
・全部独立开发（使用 golang 开发）

为什么要开发和使用自己的

・容器需要高度集成，以提供廉价的容器环境
・用户管理的容器需要持续安全
・容器资源和权限的灵活设置是可能的 它们需要是活动的（容器本身动态更改资源）
- 简而言之。 ，它们是满足要求所必需的！

整体特征

・OpenStack 和 Baremetal 的混合环境
・使用 Packer 创建的镜像极少，并且所有角色通用
・使用 Knife-Zero 代替 Terraform 的 Provisioner
・开发环境 Vagrant
・频繁发生的主要规范变更和无状态 放弃不可变基础设施的策略由于卷数较多

地形

・我尝试尽可能在模块中重用它
・毕竟tfstate是用S3管理的
・工作空间用于生产和登台
・生命周期设置对于防止事故至关重要
・我尝试在CI中进行fmt

领事

・主要是服务发现
・根据外部监控或服务监控与 Mackerel 划分角色
・使用 Consul 内部 DNS 和 Unbound 进行名称解析
・用作 Vault 存储后端
・ConsulAgent/Prometheus 所有节点的 Consul/node/blackbox 导出器 包含
・多阶段通过在垫脚石服务器上使用 Consul 解析名称，SSH 变得很方便
・使用 Consul DNS 可以实现代理上游的循环

拱顶

・使用 PKI 和 Teansit 秘密
・用 Vault 加密数据库中保存的所有秘密信息
・与 Chef 一起分发发布的秘密信息
・在延长 TTL 的同时使用令牌
・在 max-lease-ttl 时过期

PKI RootCA 分发问题

使用 TLS 连接到 Vault 服务器时应该做什么？
- 如果您使用 Consul 作为存储，vault.service.consul 将自动设置为活动 Vault
- 将 Vault 设置为证书颁发机构并自行颁发服务器证书
- Vault 将重新启动时被密封

使用控制台模板 2

・在Vault中使用SIGHUP信号重新加载服务器证书
・不使用SIGHUP进行密封
・也可用于审核日志的logrotate
・Vault颁发的根CA与Chef一起分发

应用程序Token分配问题

・应用程序向 Vault approle 进行身份验证
・通过身份验证后，会颁发具有指定 TTL 的 Token
・应用程序使用 Token 与 Vault 进行通信
・应用程序是否具有 approle 的 role_id 和 Secret_id 并不重要 否
/ 在应用程序进程之外颁发 Token

应用Token分配问题解决方案

・部署Application时执行approle auth命令
・命令为POST Secret_id的TTL扩展，即认证PW
・继续进行认证并获取Token
・将获取到的Token放在客户端可以读取的路径中应用

Vault 令牌过期并失败

- 设置为自定义secret_id以更新Approle的secret_id
- 自定义secret_id设置的token由auth/token颁发 -
每个挂载的secret都有一个max-lease-ttl设置，max-lease-ttl设置为整个系统存在ttl
- 如果两者都没有设置，上限是32天，这是系统的最大ttl
- 当令牌过期时，audit.log中经常出现403错误
- 使用Consul检查来监控audit.log Vault 服务器添加
/检测到的项目会通过 Consul Alert 通知到 Slack。

印象数

・他们在不使用 k8s 或 Docker 的情况下自己开发，这真是太神奇了。
・许多公司不使用 Terraform 的 Provisioner，而是使用其他配置管理工具。
・tfstate 编写后端并使用 S3 进行管理，它很稳定
- 我不这么认为。通常使用生命周期描述，所以我认为我需要记住它们
- Multi-stage SSH from a Step Stone 是我负责的一个项目，所以我想使用 Consul
- 说实话，我不明白跳马很好，所以我还没有充分研究它，所以我会再次记住它。 。 。

支持applibot DevOps的terraform/packer

Applibot Co., Ltd.（Cyber​​Agent Group）
规划与开发部系统运营工程师

・团队=每个应用程序的公司系统
・只有两个SYSOP（准备服务器环境的人）！
・SYSOP 经常与应用团队中的服务器工程师合作
・使用 terraform/packer 解决过去问题的故事

案例1 图像创作

・使用 RUNDECK/Ansible/Packer
・与 Ansible 结合创建机器映像
・优点：可以将映像创建流程创建为模板

・之前
・从 AMI 启动 EC2
・使用 Ansible 应用配置更改
・删除镜像服务器
・手动执行所有操作

After
一次性完成

Case02 负载测试施工

・使用 terraform/hubot
・SYSOP 构建/更改配置/审查负载测试环境

・围绕基础设施需要准备的事项
・最后，
创建一个与实际生产时间相当的环境
・在测试时创建它 ・以与实际生产相同的规模维护它会花费大量成本，因此创建它每次测试

・考试期间不使用时小
，并且有单独的网络和帐户。
・主从配置。使用 AutoScalng 扩展从站
- 创建每个测试，不使用时删除
- 各种监控
- grafana/prometheus/kibana+elasticsearch

・之前
・为管理实例运行 awscli
・用脚本调整启动顺序
・成品的秘方
・支持 sysop 端每天早晚的扩展/缩减

- 之后
- 所有组件都转换为 terraform
- 已经存在的资源可以通过 terraform import 来处理
- 如果一致性不可避免，直接修改 tfstate
- 启动管理已合并
- 通过查看 terraform 代码即可看到配置
- 创建和扩展现在可以使用 terraform apply 执行
- 使用 dependent_on 指定配置顺序
- 切换变量以减少或扩展基础设施
- 现在只需来自 slack 的通知即可完成所有操作

Case3 新环境建设

・使用 terraform/gitlab

・之前
・根帐户密封
・统一计费设置
・IAM用户创建、组创建、交换机创建
・为 CloudTrail/log 创建 S3 存储桶
・网络设置、打开监控端口

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

・为日常工作创建模板很重要！ ！

印象数

・使用 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 I想养成每次编码和查看执行计划的习惯。我
想省去去CI屏幕的麻烦（我想快速在GitHub上查看）

Mercari 上的 Hashicorp 工具

・超过 70 个微服务
・使用 Terraform 为所有微服务及其平台构建基础设施
・鼓励开发人员实践 IaC
・tfstate 数量：140
・在一个中央存储库中管理所有 Terraform 代码正在做

存储库配置

・每个微服务单独的目录
・每个服务单独的 tfstate
・每个资源单独的文件
・与 CODEOWNERS 的授权

授权

・GitHub 的功能
・未经 CODEOWNERS 中列出的人员批准才能合并
・未经许可不得更改

tfnotify 的实现

-使用io.TeeReader
-使用自己的解析器结构Terraform执行结果
-POST消息可以在Go模板中编写
-设置在YAML中

印象数

・Terraform 在中央存储库中进行管理，我担心如何使用 Git 管理代码，所以这很有帮助。
如果 tfnotify 支持 GitlabCI 和聊天工作，我会更高兴。
・也为开发人员练习 IaC。收到很重要，每次彻底检查Terraform的执行计划也很重要。我
想使用Github的CODEOWNERS功能（我想先迁移到Github...）

关于在 dwango 中使用 HashiCorp OSS

Eigo Suzuki 先生，Dwango Co., Ltd. 第二服务开发本部 Dwango 云服务部
咨询科第二产品开发部第一科

dwango 基础设施

・VMware vSphere
・AWS
・裸机
・其他一些 Azure/OpenStack 等。

dwango 中的 HashiCorp 工具

・用于创建 Packer
/Vagrant 盒子
・随着 AWS 环境的增加，用于创建 AMI
　
・
用作 Consul/ServiceDiscovery
・当 MySQL 服务器出现故障时重写应用程序配置文件
・用作 KVS 和健康检查
・用于 Ansible playbook 用作动态清单
　

用于
Terraform - 用于 NicoNico Survey、friends.nico、Nikonare、N Preparatory School 的一部分等。

Terraform 中的 CI（使用的工具）

・github
・Jenkins
・Terraform
・tfenv

Terraform 中的 CI（流）

1. 生成 PR
2. 计划 -> 应用 -> 销毁 Jenkins 中的 pr_test 环境
3. 如果 2 通过，则计划 -> 应用于沙盒环境
4. 如果一切通过，则合并

Terraform 中的 CI 有什么好处

・可以在github上查看apply是成功还是失败。
・由于环境配置是dev/prod，所以可以提前确认apply是否可以安全进行。
・使用tfenv，可以在更新terraform版本时进行检查本身很容易做到。

Terraform 中的 CD

・如果 CI 通过，我想自动将其部署到 dev 等。
・我在 Jenkins 中创建一个作业，以便可以安全地完成
。无论谁做这项工作，都可以毫无问题地部署
。结果通过 Slack 通知这样您就可以轻松检查

印象数

・Packer 方便创建 AMI
・由于我们也使用 Ansible，所以我们想使用 Consul 作为动态库存
・tfenv 的版本切换方便
・即使计划用 terraform 通过，应用时也可能会出现错误。我认为部署到 pr_test 环境是个好主意
- 毕竟 CD 是 Uncle Jenkins。创建作业比直接执行命令更容易、更可靠。

。 。 。以上内容主要是要点，但只是摘要。
我们希望积极使用HashiCorp的工具在我们公司实现IaC！