hashicorp
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseHashiCorp 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之道
- Workflows, Not Technologies: Technologies change (VMs -> Containers -> Serverless), but the workflow (Provision, Secure, Connect, Run) remains the same. Design the workflow first.
- Simple, Modular, Composable: Do one thing and do it well. Tools should be loosely coupled. The "Unix Philosophy" applied to cloud infrastructure.
- Communicating via Explicit APIs: Systems should interact through well-defined, versioned APIs, not by sharing database state or internal memory.
- 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.
- Versioning through Codification: "Infrastructure as Code." Everything—policy, security, networking—should be code, stored in version control, and reviewable.
- Automation through Codification: Since everything is code, everything can be automated. Human intervention should be the exception.
- Resilient Systems: Failure is inevitable. Design systems that expect failure and recover automatically (self-healing).
- Pragmatism: Solve real problems. Don't over-engineer.
- 工作流优先,而非技术优先:技术会不断变化(从虚拟机到容器再到无服务器),但工作流(配置、安全防护、连接、运行)始终保持一致。应先设计工作流。
- 简单、模块化、可组合:每个工具只做好一件事。工具之间应松耦合。这是「Unix哲学」在云基础设施领域的应用。
- 通过显式API通信:系统之间应通过定义清晰、带版本的API进行交互,而非共享数据库状态或内部内存。
- 不可变性:一旦创建完成,就不应再修改。若需变更,应销毁原有实例并创建新版本。这一原则适用于基础设施(服务器)、制品(容器)和配置文件。
- 通过代码化实现版本控制:即「基础设施即代码」。所有内容——策略、安全规则、网络配置——都应编码为代码,存储在版本控制系统中,并可被审核。
- 通过代码化实现自动化:既然所有内容都是代码,那么一切都可以自动化。人工干预应作为例外情况。
- 弹性系统:故障不可避免。应设计能够预判故障并自动恢复的自修复系统。
- 务实性:解决实际问题,避免过度工程化。
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 () remains constant.)
submit job反面案例(技术导向):
"我们需要构建一个Docker Swarm集群来运行应用。"
(脆弱性高。如果Kubernetes成为主流怎么办?)
正面案例(工作流导向):
"我们需要一个标准化工作流,让应用能够声明其运行时需求(CPU、内存、端口)并被调度。"
(健壮性强。调度器可以是Swarm、Nomad或K8s,用户的工作流()保持不变。)
提交任务Immutability
不可变性
BAD (Mutable Infrastructure):
bash
undefined反面案例(可变基础设施):
bash
undefinedSSH 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):**
```hclvi /etc/nginx/nginx.conf
service nginx reload
*(会出现配置漂移,产生「雪花服务器」。)*
**正面案例(不可变基础设施):**
```hclPacker 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用新实例替换旧实例。
undefinedundefinedCodification (Policy as Code)
代码化(策略即代码)
BAD:
Security team reviews a Word document checklist before deployment.
GOOD (Sentinel/OPA):
hcl
undefined反面案例:
安全团队在部署前审核一份Word文档清单。
正面案例(Sentinel/OPA):
hcl
undefinedPolicy 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的数据库。