导入并信任 GitHub Web Flow GPG 密钥 (noreply@github.com) 作者: Shine 时间: 2025-05-15 分类: 神奇技巧 评论 本指南介绍如何导入 GitHub Web Flow GPG 密钥，并手动将其信任等级设置为完全信任（ultimate），因为导入后的默认信任等级为未知。 ## 步骤 1：导入 GPG 密钥 使用以下命令导入 GitHub Web Flow GPG 密钥： ```bash curl https://github.com/web-flow.gpg | gpg --import ``` 该命令从 GitHub 下载 GPG 密钥并将其导入到您的 GPG 密钥环中。 ## 步骤 2：验证导入的密钥 导入后，您可以通过列出所有 GPG 密钥来验证密钥是否已成功添加： ```bash gpg --list-keys ``` 输出： > 其中有一个是过期的密钥，原因请参考： > * https://github.blog/news-insights/company-news/rotating-credentials-for-github-com-and-new-ghes-patches/ > * https://github.com/orgs/community/discussions/122178 ```bash pub rsa2048 2017-08-16 [SC] [过期于：2024-01-16] 5DE3E0509C47EA3CF04A42D34AEE18F83AFDEB23 uid [ 过期 ] GitHub (web-flow commit signing) <noreply@github.com> pub rsa4096 2024-01-16 [SC] 968479A1AFF927E37D1A566BB5690EEEBB952194 uid [ 未知 ] GitHub <noreply@github.com> ``` 查找与 `web-flow` 相关或 GitHub 提供的密钥 ID。输出将包含密钥的指纹和用户 ID 等详细信息，这里 KEY ID 是 `968479A1AFF927E37D1A566BB5690EEEBB952194` ## 步骤 3：将信任等级设置为完全信任 默认情况下，导入的密钥信任等级为未知，可能会在验证签名时出现问题。要将信任等级设置为完全信任，请按照以下步骤操作： 1. 启动 GPG 密钥编辑，针对特定的密钥。用实际的 GitHub Web Flow 密钥 ID 或指纹替换 `KEY_ID`： ```bash gpg --edit-key KEY_ID # gpg --edit -key 968479A1AFF927E37D1A566BB5690EEEBB952194 ``` 2. 在 GPG 提示符下，输入 `trust` 以修改信任设置： ``` gpg> trust ``` 3. 选择选项 `5` 表示完全信任： ``` 请决定您对该用户正确验证其他用户密钥的信任程度 （通过查看护照、检查不同来源的指纹等） 1 = 我不知道或不发表意见 2 = 我不信任 3 = 我略微信任 4 = 我完全信任 5 = 我绝对信任 m = 返回主菜单 您的决定？ 5 ``` 4. 确认您的选择： ``` 您真的想将此密钥设置为绝对信任吗？(y/N) y ``` 5. 保存更改并退出： ``` gpg> quit ``` 示例截图：  ## 步骤 4：验证信任等级 要确认信任等级已更新，再次列出密钥详情： ```bash gpg --list-keys ``` 输出应显示该密钥现已被设置为绝对信任。 ## 注意事项 - 请将 `KEY_ID` 替换为实际的 GitHub Web Flow 密钥 ID 或指纹，您可以在 `gpg --list-keys` 的输出中找到。 - 将密钥设置为绝对信任表示您完全信任其用于验证签名的能力。在操作前，请确保您对密钥的真实性有信心。 - 有关 GPG 密钥管理的更多信息，请参阅官方 GPG 文档或 GitHub 关于验证签名的文档。 相关参考链接： 1. https://gnupg.org/howtos/zh/GPGMiniHowto-3.html 2. https://github.blog/news-insights/company-news/rotating-credentials-for-github-com-and-new-ghes-patches/
理解 Composer 的环境变量 COMPOSER_IGNORE_PLATFORM_REQ 和 COMPOSER_IGNORE_PLATFORM_REQS 作者: Shine 时间: 2025-05-15 分类: PHP 评论 在 PHP 项目开发中，[Composer](https://getcomposer.org/) 是管理依赖的核心工具。它通过检查 PHP 环境（如版本和扩展）确保依赖兼容性。但有时我们需要在不符合平台要求的条件下安装依赖，这时环境变量 `COMPOSER_IGNORE_PLATFORM_REQ` 和 `COMPOSER_IGNORE_PLATFORM_REQS` 提供了解决方案。 ## 什么是 `COMPOSER_IGNORE_PLATFORM_REQ` 和 `COMPOSER_IGNORE_PLATFORM_REQS`？ 这两个环境变量用于绕过 Composor 的平台要求检查，平台要求包括： - PHP 版本（如 `php: ^7.4`） - PHP 扩展（如 `ext-curl`、`ext-json`） - 其他系统级依赖 当环境不满足依赖要求时，Composer 会报错并阻止安装。两者的区别在于： - **`COMPOSER_IGNORE_PLATFORM_REQ`**：允许指定忽略特定的平台要求（如 `ext-curl` 或 `php`）。 - **`COMPOSER_IGNORE_PLATFORM_REQS`**：忽略所有平台要求，等效于命令行选项 `--ignore-platform-reqs`。 ## 为什么需要忽略平台要求？ 常见场景包括： 1. **开发或测试**：本地或 CI/CD 环境的 PHP 版本或扩展与生产环境不同，但需安装依赖进行测试。 2. **临时绕过**：某些依赖在未满足官方要求的环境中仍可运行。 3. **遗留项目**：老项目依赖的包可能与新环境不完全兼容，但需继续维护。 ## 如何使用？ ### 使用 `COMPOSER_IGNORE_PLATFORM_REQ` 通过环境变量指定要忽略的特定平台要求： ```bash COMPOSER_IGNORE_PLATFORM_REQ=ext-curl composer install ``` 忽略多个要求时，用逗号分隔： ```bash COMPOSER_IGNORE_PLATFORM_REQ=ext-curl,ext-json composer update ``` ### 使用 `COMPOSER_IGNORE_PLATFORM_REQS` 若需忽略所有平台要求，设置此变量（无需指定具体要求）： ```bash COMPOSER_IGNORE_PLATFORM_REQS=1 composer install ``` 或者直接使用命令行选项： ```bash composer install --ignore-platform-reqs ``` ### 在类 Unix 平台持久化配置 在类 Unix 系统（如 Linux 或 macOS）中，可以将环境变量添加到 shell 配置文件（如 `.bashrc` 或 `.zshrc`）以持久化设置。步骤如下： 1. 打开终端，编辑配置文件（以 Zsh 为例）： ```bash nano ~/.zshrc ``` 对于 Bash，编辑 `.bashrc`： ```bash nano ~/.bashrc ``` 2. 在文件末尾添加以下行，例如忽略 `ext-curl`： ```bash export COMPOSER_IGNORE_PLATFORM_REQ=ext-curl ``` 或忽略所有要求： ```bash export COMPOSER_IGNORE_PLATFORM_REQS=1 ``` 多个特定要求： ```bash export COMPOSER_IGNORE_PLATFORM_REQ=ext-curl,ext-json ``` 3. 保存并刷新 shell 配置： ```bash source ~/.zshrc ``` 或： ```bash source ~/.bashrc ``` 4. 验证设置： ```bash echo $COMPOSER_IGNORE_PLATFORM_REQ echo $COMPOSER_IGNORE_PLATFORM_REQS ``` 此后，Composer 命令将自动应用这些设置。 ### Windows 用户 在 Windows 命令行中，临时设置语法为： ```cmd set COMPOSER_IGNORE_PLATFORM_REQ=ext-curl && composer install set COMPOSER_IGNORE_PLATFORM_REQS=1 && composer install ``` ## 潜在风险 使用这两个变量需注意： 1. **运行时错误**：忽略要求可能导致依赖在运行时因缺少扩展或版本不兼容而失败。 2. **生产环境谨慎**：建议仅在开发或测试中使用，生产环境应满足依赖要求。 3. **调试复杂**：绕过检查可能增加问题排查难度。 ## 最佳实践 - **选择合适的变量**：若只需忽略特定要求，使用 `COMPOSER_IGNORE_PLATFORM_REQ`；若需忽略全部，使用 `COMPOSER_IGNORE_PLATFORM_REQS`。 - **记录原因**：在项目文档中说明忽略平台要求的理由，便于团队理解。 - **充分测试**：忽略要求后，彻底测试应用以确保依赖正常运行。 ## 总结 `COMPOSER_IGNORE_PLATFORM_REQ` 和 `COMPOSER_IGNORE_PLATFORM_REQS` 是 Composer 的强大工具，分别用于忽略特定或全部平台要求检查。在类 Unix 系统中，通过配置 `.bashrc` 或 `.zshrc`，可以持久化这些设置，提升开发效率。但需谨慎使用，确保测试充分并避免在生产环境中引入风险。合理运用这些变量，能让 PHP 依赖管理更加灵活。
使用 MacPorts 替代 brew / 解决低版本 macOS 系统使用 brew 安装软件包慢的问题 作者: Shine 时间: 2025-05-13 分类: macOS 评论 ## 背景 根据官方的介绍，brew 仅适合 macOS 13 及更高的版本上使用了：https://docs.brew.sh/Installation#macos-requirements 对于我还在用黑苹果 macOS Big Sur 确实不友好（公司电脑 3、4 年都没更新硬件了 😓）  ## brew 替代品 - MacPorts 通过在网络搜索，很多人推荐使用 [MacPorts](https://macports.org/ "MacPorts") 替代 brew。 安装方法也很简单，下载一个安装包就可以用了，具体安装教程看这个：https://www.macports.org/install.php 以我的系统 Big Sur 为例，我就下载对应的版本安装就好了  ### 使用方法 使用方法也很简单，访问这个网站 https://ports.macports.org/ 搜索你要的软件，比如 PHP84  找到对应的版本，点击进入详情，然后就会提示你用什么命令安装，点击 Copy 返回到终端执行即可： | - | - | | ------------ | ------------ | |  |  | | |  | 网络环境好的情况下，安装速度挺快的
使用 Certimate 批量部署腾讯云 CDN 证书，解放双手 作者: Shine 时间: 2025-05-02 分类: DevOps 评论 ## Certimate 介绍 GitHub：https://github.com/usual2970/certimate 做个人产品或者在中小企业里负责运维的同学，会遇到要管理多个域名的情况，需要给域名申请证书。但是手动申请证书有以下缺点： - 😱 麻烦：申请证书并部署到服务的流程虽不复杂，但也挺麻烦的，犹其是你有多个域名需要维护的时候。 - 😭 易忘：另外当前免费证书的有效期只有 90 天，这就要求你定期的操作，增加了工作量的同时，你也很容易忘掉续期，从而导致网站访问不了。 Certimate 就是为了解决上述问题而产生的，它具有以下优势： - **本地部署**：一键安装，只需要下载二进制文件，然后直接运行即可。同时也支持 Docker 部署、源代码部署等方式。 - **数据安全**：由于是私有部署，所有数据均存储在自己的服务器上，不会经过第三方，确保数据的隐私和安全。 - **操作简单**：简单配置即可轻松申请 SSL 证书并部署到指定的目标上，在证书即将过期前自动续期，从申请证书到使用证书完全自动化，无需人工操作。 Certimate 旨在为用户提供一个安全、简便的 SSL 证书管理解决方案。 ## 我的痛点 现在免费 SSL 证书基本都是 3 个月有效期，然而我在腾讯云 CDN 部署了非常多的域名，导致每次证书更新都非常麻烦。 但是现在我可以借助 Certimate 可以很方便的管理和部署 SSL 证书到腾讯云 CDN！ 详细使用步骤建议查看 Certimate 官方文档进行操作，本片文章只是重点讲述“**使用 Certimate 批量部署腾讯云 CDN 证书**” ## 配置授权 1. 首先**新建授权**：  2. 腾讯云创建子账号，权限配置**权限策略**： - `QcloudSSLFullAccess` - `QcloudDNSPodFullAccess`（如果你的域名在腾讯云，则给予这个权限）  ## 配置 Certimate 工作流 1. 配置申请的证书，我这边申请的是 `*.nowtool.cn` 和 `nowtool.cn`  2. 按照如下图配置，特别说明：**腾讯云云产品地域**实测填写 `ap-guangzhou` 即可成功部署  ## 完成 去腾讯云控制台检查部署情况 
Kubernetes GitOps 配置架构：多环境配置管理的最佳实践 作者: Shine 时间: 2025-04-30 分类: Kubernetes,DevOps 评论 ## 背景介绍 在微服务架构和云原生应用的时代，如何有效管理多环境（开发、测试、预发布、生产）的 Kubernetes 配置成为了一个挑战。传统方法往往采用复制粘贴配置文件并修改环境特定值，这导致： 1. **维护噩梦**：相同配置散布在多个文件中，一项变更需要在多处修改 2. **配置漂移**：随着时间推移，各环境配置容易出现差异 3. **错误风险**：手动修改配置容易引入人为错误 4. **版本控制困难**：难以追踪哪些变更适用于哪些环境 为解决这些问题，本项目采用了基于 Kustomize 的 GitOps 配置架构。[Kustomize](https://kustomize.io/) 是 Kubernetes 原生的配置管理工具，允许我们在不使用模板的情况下定制资源配置。 ## 架构价值 这种架构带来几个关键优势： 1. **配置复用**：基础配置只定义一次，避免重复 2. **清晰分离**：环境特定的配置与基础配置明确分离 3. **声明式管理**：所有修改都是声明式的，使用 JSON Patch 等标准格式 4. **版本控制友好**：配置更改清晰可见，便于审计和回滚 5. **减少环境差异**：所有环境共享基础配置，减少意外差异 6. **简化运维**：标准化的配置方法降低维护成本 ## 目录结构 ``` .gitops/ ├── base/ # 基础配置，包含所有环境共用的资源定义 │ ├── deployment.yaml # 基础部署配置 │ ├── service.yaml # 服务配置 │ ├── ingress.yaml # 基础 Ingress 配置 │ └── kustomization.yaml # 基础 kustomization 文件 │ └── overlays/ # 环境特定配置（覆盖层） ├── test/ # 测试环境 │ └── kustomization.yaml # 测试环境特定的配置 ├── staging/ # 预发布环境 │ └── kustomization.yaml # 预发布环境特定的配置 └── production/ # 生产环境 └── kustomization.yaml # 生产环境特定的配置 ``` 这种结构遵循了 [Kustomize 推荐的 base/overlays 模式](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#overlay)，是管理多环境配置的标准做法。 ## 深入理解 base/overlays 模式 ### Base（基础层） `base/` 目录包含了应用的核心配置，定义了应用在任何环境中都需要的资源和设置。这些资源被设计为"默认值"，通常是开发环境或最通用的配置。基础层应当是自给自足的，可以独立部署（虽然实际应用中通常不会这样做）。 典型的基础层包括： - 部署（Deployment）定义 - 服务（Service）定义 - 基本的 Ingress 规则 - ConfigMap 和 Secret 的结构（但不包含环境特定的值） - 资源配额和限制的默认值 ### Overlays（覆盖层） `overlays/` 目录包含了每个环境的特定配置。每个环境（如 test、staging、production）都有自己的子目录，其中的 `kustomization.yaml` 文件引用了基础层，并定义了该环境需要的修改。 覆盖层不是完整的独立配置，而是对基础层的补充或修改。它们通过各种补丁机制（如 strategic merge patches、JSON patches）来调整基础配置以适应特定环境的需求。 ## 使用方法 ### 基础配置 基础配置在 `base/` 目录中定义，包括所有环境通用的资源。这些资源会被各环境的 overlay 配置引用并根据需要进行修改。 一个典型的基础 `kustomization.yaml` 文件看起来像这样： ```yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - deployment.yaml - service.yaml - ingress.yaml commonLabels: app: my-application ``` ### 环境特定配置 每个环境在 `overlays/` 目录下有自己的子目录（如 `test/`、`staging/`、`production/`）。这些目录中的 `kustomization.yaml` 文件会引用基础配置，并应用环境特定的修改。 #### 为什么需要修改 Ingress 主机名？ 在多环境部署中，我们通常需要为不同的环境配置不同的访问域名。这有几个重要原因： 1. **环境隔离**：每个环境（开发、测试、预发布、生产）需要有自己独立的访问入口，以避免相互干扰 2. **访问控制**：可以对不同环境的域名实施不同的访问控制策略（如测试环境仅内网访问） 3. **DNS 管理**：通过子域名区分环境，使 DNS 管理更加清晰 4. **监控和分析**：可以单独监控每个环境的流量和性能 5. **SSL 证书**：不同环境可能需要不同的 SSL 证书配置 #### 实际案例说明 假设我们有一个名为 "myapp" 的应用程序，需要在多个环境中部署。下面是一个真实案例的域名规划： | 环境 | 主域名 | API 域名 | 其它服务域名 | |------|--------|---------|------------| | 生产环境 | myapp.example.cc | api.example.cc | webhook.example.cc | | 预发布环境 | staging.example.cc | api-staging.example.cc | webhook-staging.example.cc | | 测试环境 | my-test.example.cc | api-test.example.cc | webhook-test.example.cc | | 开发环境 | dev.example.cc | api-dev.example.cc | webhook-dev.example.cc | 在基础配置（base/ingress.yaml）中，我们可能定义了生产环境的域名： ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nowtime-main-backend-ingress spec: rules: - host: myapp.example.cc http: paths: - path: / pathType: Prefix backend: service: name: main-service port: number: 80 - host: api.example.cc http: paths: - path: / pathType: Prefix backend: service: name: api-service port: number: 80 ``` 而在测试环境的配置中，我们需要将这些域名替换为测试环境的域名。这就是为什么我们在 `overlays/test/kustomization.yaml` 中使用 patches 修改主机名： ```yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: nowtime-test # 设置命名空间 resources: - ../../base # 引用基础配置 patches: - patch: |- - op: replace path: /spec/rules/0/host value: my-test.example.cc - op: replace path: /spec/rules/1/host value: api-test.example.cc - op: replace path: /spec/rules/2/host value: webhook-test.example.cc - op: replace path: /spec/rules/3/host value: url-test.example.cc target: kind: Ingress name: nowtime-main-backend-ingress ``` 这种方法的优势在于： - **集中管理**：所有环境特定的域名都集中在一个文件中管理 - **一目了然**：可以清晰地看到该环境使用的所有域名 - **减少错误**：避免复制整个 Ingress 定义时可能引入的错误 - **便于审计**：域名变更记录清晰可见 - **自动化友好**：可以轻松集成到 CI/CD 流程中 #### 部署验证 应用配置后，可以检查 Ingress 是否正确配置了测试环境的域名： ```bash # 查看生成的完整 Ingress 配置 kubectl kustomize .gitops/overlays/test/ | grep -A 10 "kind: Ingress" # 应用配置并检查实际 Ingress 资源 kubectl apply -k .gitops/overlays/test/ kubectl get ingress -n nowtime-test kubectl describe ingress nowtime-main-backend-ingress -n nowtime-test ``` 验证 Ingress 控制器是否正确路由请求： ```bash # 测试域名解析（需确保 DNS 已配置或添加到本地 hosts 文件） curl -I https://my-test.example.cc curl -I https://api-test.example.cc ``` ## 常见操作实践 ### 修改命名空间 在 Kubernetes 中，命名空间是实现多租户和资源隔离的关键机制。在多环境架构中，每个环境通常都有自己的命名空间。 在每个环境的 `kustomization.yaml` 文件中设置 `namespace` 字段： ```yaml namespace: nowtime-test ``` 这会将引用的所有资源的命名空间修改为指定值，无需手动修改每个资源文件。 ### 修改 Ingress 主机名 在多环境架构中，不同环境通常有不同的访问域名。使用 JSON Patch 操作来修改 Ingress 规则中的主机名： ```yaml patches: - patch: |- - op: replace path: /spec/rules/0/host value: your-new-hostname.example.cc target: kind: Ingress name: your-ingress-name ``` 这种方法比完全重定义 Ingress 资源更简洁、更不容易出错。 ### 修改副本数 不同环境通常需要不同规模的部署。例如，生产环境可能需要多个副本以实现高可用性和负载均衡，而测试环境可能只需要一个副本以节省资源。 ```yaml patches: - patch: |- - op: replace path: /spec/replicas value: 3 target: kind: Deployment name: your-deployment-name ``` ### 添加环境变量 环境变量是配置应用行为的常用方法，不同环境可能需要不同的环境变量值。 ```yaml patches: - patch: |- - op: add path: /spec/template/spec/containers/0/env/- value: name: ENV_NAME value: "env_value" target: kind: Deployment name: your-deployment-name ``` ## JSON Patch 详解 [JSON Patch (RFC 6902)](https://datatracker.ietf.org/doc/html/rfc6902) 是一种用于描述对 JSON 文档的修改的标准格式。在 Kustomize 中，它是实现精细化配置修改的强大工具。 JSON Patch 定义了六种操作： - `add`: 添加一个值 - `remove`: 删除一个值 - `replace`: 替换一个值 - `move`: 移动一个值 - `copy`: 复制一个值 - `test`: 测试一个值是否匹配 路径使用 [JSON Pointer (RFC 6901)](https://datatracker.ietf.org/doc/html/rfc6901) 格式表示，例如 `/spec/replicas` 指向 JSON 文档中的 `spec.replicas` 字段。 ## 部署应用 使用 Kustomize 部署应用非常简单，只需指定环境的 overlay 目录即可。 ```bash # 查看生成的资源（不实际应用） kubectl kustomize .gitops/overlays/test/ # 应用配置 kubectl apply -k .gitops/overlays/test/ ``` Kubernetes 1.14+ 内置了 Kustomize 支持，不需要单独安装 Kustomize 命令行工具。 ## GitOps 工作流 这种配置架构非常适合 GitOps 工作流，将 Git 作为唯一的事实来源： 1. 所有配置变更通过 Git 仓库进行 2. CI/CD 系统监控仓库变更 3. 变更合并后自动应用到相应环境 4. 集群状态始终与 Git 仓库中的定义一致 推荐的工具有 [Flux](https://fluxcd.io/) 和 [ArgoCD](https://argoproj.github.io/argo-cd/)，它们可以自动监控仓库并将变更应用到集群。 ## 相关资源 - [Kustomize 官方文档](https://kubectl.docs.kubernetes.io/references/kustomize/) - [Kubernetes Kustomize 指南](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/) - [JSON Patch 规范 (RFC 6902)](https://datatracker.ietf.org/doc/html/rfc6902) - [Kustomize Patches 文档](https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/patches/) - [Kustomize GitHub 仓库](https://github.com/kubernetes-sigs/kustomize) - [GitOps 工作组](https://github.com/open-gitops/open-gitops) ## 最佳实践 1. **保持基础配置通用**：基础配置应包含所有环境共享的设置，环境特定的设置应在 overlay 中处理。避免在基础配置中硬编码环境特定的值。 2. **使用版本控制**：所有配置更改都应经过版本控制，便于跟踪变更和回滚。使用 Git 分支模型管理不同环境的配置更新流程。 3. **使用 CI/CD 流水线**：自动部署配置更改，减少手动错误。配置应该在部署前自动验证和测试。 4. **命名规范**：使用一致的命名约定，使资源之间的关系更加清晰。建议在资源名称中包含应用名和环境标识。 5. **限制对基础配置的修改**：优先通过 patches 修改配置，而不是更改基础资源文件。这保持了配置的清晰分离。 6. **明确文档化**：记录每个环境的特殊配置和差异原因，帮助团队成员理解配置决策。 7. **使用环境变量和 ConfigMap**：将配置参数外部化，避免硬编码配置值。 8. **实施安全控制**：对不同环境的访问权限实施适当的 RBAC 控制，尤其是生产环境。 --- 通过这种架构，我们能够实现配置的 DRY（Don't Repeat Yourself）原则，大大减少了跨环境维护 Kubernetes 配置的工作量和错误风险。它为我们提供了一种标准化、可靠且可扩展的方法来管理应用在从开发到生产的整个生命周期中的配置。