在 Terrateam 上跑通 Terragrunt Stacks：一次从「完全不行」到「能跑但不放心」的踩坑实录
写在前面:这不是一篇官方文档的转述,是一次真实的、边打边退边进的调试记录。结论会在文章的最后给出,但我更想把中间踩过的每一个坑原样写下来——因为这些坑大多数没有任何文档提到,靠的是直接读 Terrateam 的 OCaml 源码、盯着 GitHub Actions 的原始日志一行行抠、以及若干次”看起来应该好了但其实还没有”的假阳性。如果你也在搞 Terragrunt 单体仓库(monorepo)+ Terrateam,大概率会撞上这里面的某一个坑,希望能帮你少走几步。 TL;DR Terrateam 官方支持 Stack 的方式(config_builder 自带的 terragrunt-config-builder 脚本)是不管用的——它压根不解析 terragrunt.stack.hcl。 官方文档承诺的 dirs.create_if_missing 字段,在决定”这个目录算不算数”的那行判断逻辑里,确实没有被检查——这是穷举全部源码 + 定位到具体判断函数后拿到的结论,不是猜测。但这不等于”这个字段从没在任何人的场景里生效过”(详见第二章、第三章的验证过程和澄清)。 ...
Terragrunt 三层 include：我们是怎么在 OKE 的 Terraform 配置里做到 DRY 的
前面两篇分别照着 Gruntwork 官方的两个示例仓库，讲了 Infrastructure-Catalog（可复用模式怎么组织、怎么版本化）和 Infrastructure-Live + Stacks（account/region 分层、自动依赖解析）。这一篇本来的计划是：回到我们自己真实维护的 OCI OKE Terraform 仓库，诚实地承认这两套模式对我们这个规模不大的仓库”暂时用不上”。 草稿写到一半，我们真的把 Terraform 仓库做了一轮重构——不是为了写这篇文章去凑素材，是业务上确实需要（新集群、新的对等网络越来越多，重复配置的维护成本已经真实地疼了）。所以这一篇的后半段整个重写了：先讲我们最初、也是现在仍在用的三层 include 结构，再回头看 Catalog 和 Stacks 这两套官方模式——这次不是”套上去看合不合适”，是真实用出来之后，踩过的坑和官方例子完全不一样。 起点：只有一个环境接入 Terragrunt 的时候写前两篇的时候，我们在 OCI 上运营着好几个 OKE 集群，但只有 oke-prod-us-ashburn-2 这一...
Terragrunt Stacks 与 Infrastructure-Live：account/region 分层与自动依赖解析
上一篇讲了 Infrastructure-Catalog——一堆经过验证的可复用基础设施模式，用 modules/units/stacks 组织，靠 git tag 版本化。但 catalog 只回答”能部署什么”，不回答”实际部署了什么”。后者是 Infrastructure-Live 仓库的职责，这一篇照着 Gruntwork 官方的 terragrunt-infrastructure-live-stacks-example 讲。 1. Infrastructure-Live 与 Infrastructure-Catalog 的分工官方的定义很直接： An infrastructure-live repository is a Gruntwork best practice for managing your “live” infrastructure. That is, the infrastructure that is actually provisioned, as opposed to infrastructure patterns that can be p...
Terragrunt 的 Infrastructure-Catalog 模式：可复用基础设施怎么组织
系列第一篇讲了 module/unit/stack 这三个术语，用的是一个只有一个 unit 的最小例子。真实场景里，一个团队往往要维护几十上百种可复用的基础设施模式——数据库、消息队列、Lambda 服务、安全组……这些模式怎么组织、怎么让别人安全地复用，是 Terragrunt 生态里 Infrastructure-Catalog 这套约定要解决的问题。这一篇照着 Gruntwork 官方的 terragrunt-infrastructure-catalog-example 仓库讲。 1. 什么是 Infrastructure-Catalog按官方的定义： An infrastructure-catalog is a repository that contains the best practice infrastructure patterns you or your organization wants to use across your infrastructure estate. This is a Git repository that...
Terragrunt 是什么，为什么要用它——从一个最小例子开始
这是一个 Terragrunt 系列的第一篇。后面两篇会照着 Gruntwork 官方的两个示例仓库，讲 Infrastructure-Catalog（可复用模式怎么组织、怎么版本化）和 Infrastructure-Live + Stacks（account/region 分层、自动依赖解析）这些进阶话题；最后一篇回到我们自己维护的 OCI OKE 集群 Terraform 仓库，看这些模式实际落地能用上几分。但在那之前，先花一篇讲清楚 Terragrunt 到底是什么、解决什么问题——这样后面每一篇里的设计选择，才有地方”挂”。 1. 先说清楚它解决的问题如果你已经会用 Terraform/OpenTofu，通常会在多个环境（dev/test/prod）之间遇到几件重复的事： backend 和 provider 配置要在每个环境目录里抄一遍。 这些配置几乎不随环境变化，但纯 Terraform 没有”全局共享一份配置”的机制，只能复制粘贴。 同一份模块代码，不同环境只是参数不同。 你要么维护一堆 dev.tfvars/...
从 Cluster Autoscaler 到 Karpenter：OKE 节点弹性伸缩的 ArgoCD 实践
Karpenter Provider for OCI（下面简称 KPO）是 Oracle 官方维护的、把 Karpenter 这套”按 Pod 需求直接算节点”的弹性伸缩方案移植到 OKE 上的实现。它是什么、NodePool/OCINodeClass 这两个 CRD 怎么设计的，官方 GitHub 和 Oracle 文档 已经写得很全了。这篇文章记录的是另一件事：我们把 KPO 接进 ArgoCD 之后，为什么又在它前面自己包了一层 Terraform + Helm，以及这一路踩过的几个坑。 1. 为什么从 Cluster Autoscaler 换到 Karpenter我们新建的几个 OKE 集群里，Terraform 的 worker_pools 只声明了一个兜底节点池，Cluster Autoscaler 相关的输入直接传了个空 map： 12# 不安装 ClusterAutoscaler add-on（空 map => 模块内 addon count=0），改用 Karpentercluster_autoscaler = {} 动...
用 ArgoCD 把 OKE 集群从 Flannel 迁移到 Cilium：一次 GitOps 实践
网上关于「OKE 把 CNI 从 Flannel 换成 Cilium」的教程不少，比如 Pratik Borkar 的这篇 和 Oracle 官方的 Learn 教程，写得都很扎实。但它们都是「站在一台笔记本前敲命令」的视角：helm repo add、手改一份几百行的 cilium.yaml、helm install，最后再手动 kubectl delete daemonset kube-flannel-ds——这一步在我们的场景里其实行不通（下面第 6 步会讲为什么）。 这套流程在一个集群上没问题。但当你手上有好几个 OKE 集群——生产、生产的第二个 region、专门跑 ops 组件的集群、还有 QA 环境——手工敲命令的方式很快就会出问题：配置漂移（这个集群改了参数忘记同步到那个集群）、没有变更记录（谁在什么时候把 kubeProxyReplacement 打开的？）、也没有办法方便地做 diff/回滚。 所以这篇文章记录的是我们实际在生产里怎么做的：用 ArgoCD 的 ApplicationSet，把 Cilium 的安装和多集群管理全部变成 GitOps...
在MacBook M2上构建多架构Docker镜像
在最新的MacBook M2笔记本上，你可能希望构建能够在多种架构上运行的Docker镜像。由于M2芯片基于ARM架构，这为我们提供了一个理想的环境来构建和测试多平台镜像。以下是在MacBook M2上构建多架构Docker镜像的步骤。 1. 安装Docker Desktop for Mac首先，确保你已经安装了最新版本的Docker Desktop for Mac。这个版本的Docker Desktop专为Apple Silicon优化，并支持多平台构建。 2. 创建Buildx构建器使用以下命令创建一个新的Buildx构建器实例，指定你想要支持的平台： 1docker buildx create --use --platform=linux/arm64,linux/amd64 --name multi-platform-builder 3. 构建多平台镜像使用docker buildx build命令来构建多平台镜像。例如： 1docker buildx build --platform=linux/arm64,linux/amd64 --push --tag project...
在 Kubernetes 中使用 External-DNS 管理域名
简介在 Kubernetes 集群中，管理域名和将服务公开到外部网络是一个关键的任务。External-DNS 是一个强大的工具，它允许您通过 Kubernetes 资源来自动管理域名。这篇文章将介绍如何在 Kubernetes 中使用 External-DNS，以便轻松地将服务关联到域名，并确保域名与服务的 IP 地址保持同步。 接下来我就以我自身的一个实际用例来介绍一下。 安装 External-DNS首先，您需要安装 External-DNS 到您的 Kubernetes 集群。可以使用 Helm 来简化这个过程。执行以下命令： 1234helm repo add bitnami https://charts.bitnami.com/bitnamihelm install external-dns bitnami/external-dns \ --set provider=your-dns-provider \ --set provider.apiKey=your-api-key 请替换 your-dns-provider 和 your-api-key 为您的 DNS...
极路由hc5761刷openwrt
本篇进入主题，将按照以下步骤把极路由HC5761刷成opentwrt系统。如果你的极路由还没有刷回官方原厂固件，需要先完成上一篇：极路由hc5761刷openwrt 之 刷原厂固件。 root路由器，开启SSH 输入bread 进入bread模式，修改mac地址 在bread模式中刷入openwrt固件 博主的操作环境电脑: MacBook系统: MacOS Ventura v13.6路由器: Hiwifi HC5761版本: 0.9012.1.9277s root路由器，开启SSH博主在这里整理了三种方法 1.纯手动操作 访问http://192.168.199.1/local-ssh/ 获取local_token 访问http://192.168.199.1/cgi-bin/turbo/proxy/router_info地址，在返回的json中找到uuid， 返回https://www.hiwifi.wtf/网站，填入local_token和uuid提交后就可以获得cloud token 进入路由器http://192.168.199.1/local-ssh/页面，填入第...