hashicorp

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

HashiCorp Style Guide

HashiCorp风格指南

Overview

概述

HashiCorp is defined by its "Tao," a set of engineering principles that guided the creation of tools like Terraform, Consul, Vault, and Nomad. These principles focus on solving the right problems with the right level of abstraction, favoring consistent workflows for users even as the underlying technologies change.
HashiCorp的核心是其「道」(Tao),这是一套指导Terraform、Consul、Vault和Nomad等工具开发的工程原则。这些原则专注于用恰当的抽象层级解决正确的问题,即便底层技术发生变化,也始终为用户提供一致的工作流。

The Tao of HashiCorp

HashiCorp之道

  1. Workflows, Not Technologies: Technologies change (VMs -> Containers -> Serverless), but the workflow (Provision, Secure, Connect, Run) remains the same. Design the workflow first.
  2. Simple, Modular, Composable: Do one thing and do it well. Tools should be loosely coupled. The "Unix Philosophy" applied to cloud infrastructure.
  3. Communicating via Explicit APIs: Systems should interact through well-defined, versioned APIs, not by sharing database state or internal memory.
  4. Immutability: Once something is created, it should not change. To change it, destroy it and create a new version. This applies to infrastructure (servers), artifacts (containers), and configurations.
  5. Versioning through Codification: "Infrastructure as Code." Everything—policy, security, networking—should be code, stored in version control, and reviewable.
  6. Automation through Codification: Since everything is code, everything can be automated. Human intervention should be the exception.
  7. Resilient Systems: Failure is inevitable. Design systems that expect failure and recover automatically (self-healing).
  8. Pragmatism: Solve real problems. Don't over-engineer.
  1. 工作流优先,而非技术优先:技术会不断变化(从虚拟机到容器再到无服务器),但工作流(配置、安全防护、连接、运行)始终保持一致。应先设计工作流。
  2. 简单、模块化、可组合:每个工具只做好一件事。工具之间应松耦合。这是「Unix哲学」在云基础设施领域的应用。
  3. 通过显式API通信:系统之间应通过定义清晰、带版本的API进行交互,而非共享数据库状态或内部内存。
  4. 不可变性:一旦创建完成,就不应再修改。若需变更,应销毁原有实例并创建新版本。这一原则适用于基础设施(服务器)、制品(容器)和配置文件。
  5. 通过代码化实现版本控制:即「基础设施即代码」。所有内容——策略、安全规则、网络配置——都应编码为代码,存储在版本控制系统中,并可被审核。
  6. 通过代码化实现自动化:既然所有内容都是代码,那么一切都可以自动化。人工干预应作为例外情况。
  7. 弹性系统:故障不可避免。应设计能够预判故障并自动恢复的自修复系统。
  8. 务实性:解决实际问题,避免过度工程化。

Prompts

提示模板

Platform Engineering Design

平台工程设计

"Act as a HashiCorp Systems Architect. Design a platform for our internal developers.
Focus on:
  • Workflow Abstraction: How do developers deploy? Does it change if we move from AWS to Azure? (It shouldn't).
  • Composability: Are we building a monolith platform or composing small tools?
  • Self-Service: How can we use code (HCL, YAML) to let developers serve themselves?"
"请扮演HashiCorp系统架构师,为我们的内部开发者设计一个平台。
重点关注:
  • 工作流抽象:开发者如何部署应用?当我们从AWS切换到Azure时,部署流程是否需要改变?(答案应该是不需要)
  • 可组合性:我们是构建单体平台,还是组合小型工具来搭建?
  • 自助服务:如何通过代码(HCL、YAML)让开发者实现自助服务?"

Workflow Review

工作流审核

"Review this CI/CD pipeline against the Tao of HashiCorp.
Questions:
  • Immutability: Are we patching running servers (Mutable) or replacing them (Immutable)?
  • Codification: Is the security policy defined in a GUI or in code (Sentinel/OPA)?
  • Explicit APIs: Are the build and deploy steps decoupled?"
"对照HashiCorp之道审核这个CI/CD流水线。
问题:
  • 不可变性:我们是对运行中的服务器打补丁(可变),还是直接替换服务器(不可变)?
  • 代码化:安全策略是通过GUI定义,还是通过代码(Sentinel/OPA)定义?
  • 显式API:构建和部署步骤是否解耦?"

Examples

示例

Workflows > Technologies

工作流 > 技术

BAD (Technology Focused): "We need to build a Docker Swarm cluster to run our apps." (Fragile. What happens when Kubernetes wins?)
GOOD (Workflow Focused): "We need a standardized workflow for applications to declare their runtime requirement (cpu, mem, ports) and be scheduled." (Robust. The scheduler can be Swarm, Nomad, or K8s. The user workflow (
submit job
) remains constant.)
反面案例(技术导向): "我们需要构建一个Docker Swarm集群来运行应用。" (脆弱性高。如果Kubernetes成为主流怎么办?)
正面案例(工作流导向): "我们需要一个标准化工作流,让应用能够声明其运行时需求(CPU、内存、端口)并被调度。" (健壮性强。调度器可以是Swarm、Nomad或K8s,用户的工作流(
提交任务
)保持不变。)

Immutability

不可变性

BAD (Mutable Infrastructure):
bash
undefined
反面案例(可变基础设施):
bash
undefined

SSH into server

SSH登录服务器

ssh admin@server-01 apt-get update apt-get install nginx
ssh admin@server-01 apt-get update apt-get install nginx

Edit config file effectively in production

在生产环境中直接编辑配置文件

vi /etc/nginx/nginx.conf service nginx reload
*(Drift happens. Snowflake servers emerge.)*

**GOOD (Immutable Infrastructure):**
```hcl
vi /etc/nginx/nginx.conf service nginx reload
*(会出现配置漂移,产生「雪花服务器」。)*

**正面案例(不可变基础设施):**
```hcl

Packer Template to build image

用于构建镜像的Packer模板

source "amazon-ebs" "ubuntu" { ami_name = "nginx-web-{{timestamp}}"

...

}
build { sources = ["source.amazon-ebs.ubuntu"] provisioner "shell" { inline = [ "apt-get install -y nginx", "mv /tmp/nginx.conf /etc/nginx/nginx.conf" ] } }
source "amazon-ebs" "ubuntu" { ami_name = "nginx-web-{{timestamp}}"

...

}
build { sources = ["source.amazon-ebs.ubuntu"] provisioner "shell" { inline = [ "apt-get install -y nginx", "mv /tmp/nginx.conf /etc/nginx/nginx.conf" ] } }

Result: An AMI ID.

结果:一个AMI ID。

To update: Build new AMI, replace old instances with new ones via Terraform/ASG.

更新方式:构建新的AMI,通过Terraform/ASG用新实例替换旧实例。

undefined
undefined

Codification (Policy as Code)

代码化(策略即代码)

BAD: Security team reviews a Word document checklist before deployment.
GOOD (Sentinel/OPA):
hcl
undefined
反面案例: 安全团队在部署前审核一份Word文档清单。
正面案例(Sentinel/OPA):
hcl
undefined

Policy explicitly defined in code

用代码明确定义策略

import "tfplan"
main = rule { all tfplan.resource_changes as _, rc { rc.type is "aws_security_group" implies all rc.change.after.ingress as ingress { ingress.cidr_blocks not contains "0.0.0.0/0" } } }
*(Automated. Versioned. Auditable.)*
import "tfplan"
main = rule { all tfplan.resource_changes as _, rc { rc.type is "aws_security_group" implies all rc.change.after.ingress as ingress { ingress.cidr_blocks not contains "0.0.0.0/0" } } }
*(自动化、带版本控制、可审计。)*

Anti-Patterns

反模式

  • The "Golden Hammer": Using one tool for everything (e.g., using Terraform to configure OS internals instead of Ansible/Packer).
  • ClickOps: Managing infrastructure via the AWS Console UI.
  • Long-Lived Pets: Servers that are never destroyed because "we don't know how to rebuild them."
  • Implicit Dependencies: Service A reads Service B's database directly.
  • 「黄金锤子」:用一种工具解决所有问题(例如,用Terraform配置操作系统内部,而非使用Ansible/Packer)。
  • ClickOps:通过AWS控制台UI管理基础设施。
  • 长期存活的「宠物服务器」:服务器从不被销毁,因为「我们不知道如何重建它们」。
  • 隐式依赖:服务A直接读取服务B的数据库。

Resources

参考资源