分类： 杂记

杂记

西门子洗碗机SN23E831TI排水泵故障维修

最近家里的西门子洗碗机不工作了，故障表现就是洗碗不结束，面板上的进水龙头指示灯闪烁，永远不结束。仔细观察，触摸洗碗机，会发现洗碗机外部凉凉的，不加热。洗碗中途打开柜门，里面没有温度。只要没有温度，大概率故障原因就是加热模块损坏。

继续阅读西门子洗碗机SN23E831TI排水泵故障维修

访问github.com被解析到127.0.0.1问题解决

最近访问 github，发现总是访问失败。经过排查后确认问题原因是 DNS 解析被污染导致 github.com 被解析到 127.0.0.1 导致的。

如下图：

解决方案：

1、指定DNS为其他知名DNS服务器：如1.1.1.1，8.8.8.8， 114.114.114.114等；

2、添加hosts文件记录，将github的ip地址增加进去。

参考链接

H3CBook Pro 14 G2合盖睡眠导致指纹解锁不可用M2硬盘丢失问题

公司新发的 H3CBook Pro 14 G2 使用了 Intel i7 1360P 当前 BIOS 版本号 F.11 版本日期 12/27/2024 。机器自带内存 16GB，感觉不大够用。到手之后，买了一个新的 32GB DDR5 内存，顺手插上了老电脑上替换下来的一个 Intel M2 固态硬盘。默认情况下合盖会进入自动睡眠状态。重新打开盖子，指纹解锁不可用，进入系统之后，新增的 M2 硬盘丢失。重启系统后可以恢复。

跟客服也沟通了一下，目前暂时没有新的 BIOS 版本发布。目前的解决方案就是在 Windows 11 的电源设置里面关闭合盖 “睡眠” 选项，全部设置为 “休眠”。

API 版本迭代，怎么进行 API 多版本处理？

API 版本迭代是在软件开发过程中非常常见的一种需求，尤其对于 Web API 来说，随着业务需求的不断变化和技术的发展，API 的版本迭代变得愈发重要。API 版本迭代的目的是为了满足不断变化的业务需求、修复缺陷和改进功能，同时保持向后兼容性。然而，随着多个版本的 API 共存，如何进行多版本处理成为了必不可少的问题。

为什么需要进行版本迭代？
  1. 向后兼容性：在引入新功能或修改现有功能的同时，应该尽可能保持与现有版本的 API 的兼容，避免对已有客户端和应用程序的影响。
  2. 兼容性测试：为了确保新版本 API 的稳定性，需要进行兼容性测试。可以通过多版本处理来降低测试的成本和风险。
  3. 用户体验：通过多版本处理来提供更好的用户体验，向用户和开发者提供更多的选择和灵活性，使其能够逐步升级到新版本而不会影响其业务。
    因此，API 多版本处理对于确保系统的稳定性、提高开发效率和用户体验至关重要。
常见的 API 迭代模式

API 版本迭代需要进行版本控制，以便开发者和用户能清晰地了解各个版本之间的差异和兼容性情况。常见的 API 版本迭代模式包括语义版本控制（Semantic Versioning），它是一种广泛应用于软件开发领域的版本号命名规范。

语义版本控制将版本号分为主版本号、次版本号和修订号三个部分，分别代表了不同层次的变化：

  • 主版本号：当你做了不兼容的 API 修改时，需要升级主版本号。
  • 次版本号：当你做了向下兼容的功能性新增时，需要升级次版本号。
  • 修订号：当你做了向下兼容的问题修正时，需要升级修订号。
    语义版本控制的优点在于，通过版本号的规范化命名，能够清晰地表达版本之间的关系和变化。开发者和用户可以根据版本号了解这个版本带来了什么样的变化，以及对其现有应用的影响。这有助于提高版本变更的可预测性和透明度。

多版本处理的挑战

多版本处理是 API 设计中常见的问题之一。当 API 需要支持多个版本时，可能会遇到以下挑战：

  • 兼容性：不同版本的 API 可能存在不兼容的情况，导致客户端无法访问或使用所需版本的 API。
  • 功能冲突：不同版本的 API 可能包含不同的功能，导致客户端在使用不同版本的 API 时遇到功能冲突。
  • 对用户的影响：API 版本的变化可能会对用户的使用体验产生影响，例如用户需要升级客户端软件或重新学习如何使用 API。
  • 对开发者的影响：API 版本的变化可能会给开发者带来额外的开发和维护工作，例如开发者需要维护多个版本的 API 文档和代码库。
解决方案一：URI 版本控制

URI 版本控制是一种通过在 API 的 URI 中包含版本号来区分不同版本的 API 的方法。这种方法简单易懂，并且支持大部分客户端工具。

解决方案 URI 版本控制
概念 API 版本作为 URI 的一部分，如/api/v1/users表示第一个版本，/api/v2/users表示第二个版本。客户端通过在请求中指定 URI 版本号选择 API 版本。
优点
 简单易懂：概念直观，易于理解。
  广泛支持：得到大部分客户端工具支持，包括浏览器、HTTP 客户端库和 RESTful API 框架。
  独立部署：不同 API 版本可独立部署，有利于开发和维护。
缺点 冗长：每个 URI 中包含版本号导致 URI 冗长。
  版本冲突：存在不同 API 版本时可能发生冲突，导致客户端无法访问所需版本。
  难以发现：URI 中包含版本号可能使客户端难以发现新 API 版本。
适用场景 API 版本较少且不经常更新。
  客户端工具支持 URI 版本控制。
  API 需要与多种客户端工具兼容。
解决方案二：标头版本控制

标头版本控制是一种通过在请求头中包含版本号来区分不同版本的 API 的方法。这种方法与 URI 版本控制相似，但更加灵活，并且可以支持更多类型的客户端工具。

解决方案 标头版本控制
概念 API 版本作为请求头的一部分，例如，使用Accept: application/json; version=2表示客户端请求使用 API 的第二个版本。服务器根据请求头中的版本号选择 API 版本。
优点 灵活：更加灵活，支持多种客户端工具，包括浏览器、HTTP 客户端库和 RESTful API 框架。
  版本独立：与 URI 无关，不同 API 版本可以在同一个 URI 上部署。
  易于发现：通过请求头可以发现新的 API 版本。
缺点 复杂性：概念较复杂，可能需要客户端工具特殊处理。
  兼容性：需要客户端工具支持，否则无法使用。
  性能：可能影响性能，因为服务器需要额外处理请求头。
适用场景 API 版本较多且经常更新。
 
客户端工具支持标头版本控制。
  API 需要与多种类型的客户端工具兼容。
解决方案三：内容协商

内容协商是一种根据客户端的需求动态选择合适的 API 版本的机制。这种机制允许客户端在请求中指定它支持的 API 版本，然后服务器根据客户端支持的版本选择要使用的 API 版本。

解决方案 内容协商
概念 根据客户端需求动态选择合适的 API 版本，通过 HTTP 协议中的Accept和Content-Type请求头指定客户端支持的版本和内容类型。服务器根据请求头信息选择 API 版本和内容类型。
优点 动态选择：允许客户端动态选择合适的 API 版本，更容易适应客户端需求。
  兼容性：允许客户端使用不同的 API 版本，提高 API 兼容性。
  性能：提高性能，服务器可以根据客户端需求选择最合适的 API 版本和内容类型。
缺点 复杂性：概念较复杂，需要客户端工具和服务器特殊处理。
  兼容性：需要客户端工具和服务器都支持内容协商，否则无法使用。
适用场景 API 版本较多且经常更新。
  客户端工具和服务器都支持内容协商。
  API 需要与多种类型的客户端工具兼容。
通过 Apifox 进行版本控制

Apifox 是一个集接口文档、API 调试、自动化测试、Mock 服务等功能于一体的综合 API 开发协作工具。Apifox = Postman + Swagger + Mock + JMeter，Apifox 支持调试 http(s)、WebSocket、Socket、gRPC、Dubbo 等协议的接口，并且集成了 IDEA 插件。

原始链接

API 版本迭代，怎么进行 API 多版本处理？

商用密码32款认证产品、功能及认证依据详细介绍

为贯彻落实《中华人民共和国密码法》,建立完善商用密码产品认证体系，市场监管总局、国家密码管理局根据《国家密码管理局  市场监管总局关于调整商用密码产品管理方式的公告》（第39号）分别于2020年、2022年及2025年连续发布三次商用密码产品目录，相关商用密码认证检测均依据此目录进行产品检测、认证。

以下是截止2025年3月27日，全量商用密码产品门类/目录，看看哪些是大家所了解和擅长的密码产品，具体如下：

第一批商用密码产品名录

市场监管总局 国家密码管理局于2020年5月11日发布《商用密码产品认证目录（第一批）》，具体如下：

1、智能密码钥匙  

  • 产品名称：智能密码钥匙  
  • 功能描述：实现密码运算、密钥管理功能的终端密码设备，一般使用 USB 接口形态。  
  • 认证依据：  

1）GM/T 0027《智能密码钥匙技术规范》  

2）GM/T 0028《密码模块安全技术要求》

2、智能 IC 卡

  • 产品名称：智能 IC 卡  
  • 功能描述：实现密码运算和密钥管理功能的含 CPU 的集成电路卡，包括应用于金融等行业领域的智能 IC 卡。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0041《智能 IC 卡密码检测规范》

3、POS/ATM/多功能/互联网终端密码应用系统  

  • 产品名称：POS 密码应用系统、ATM 密码应用系统、多功能密码应用系统、互联网终端  
  • 功能描述：为金融终端设备提供密码服务的密码应用系统。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）JR/T 0025-2018《中国金融集成电路 (IC) 卡规范 第 7 部分：借记贷记应用安全规范》

4、PCI-E/PCI 密码卡  

  • 产品名称：PCI-E/PCI 密码卡  
  • 功能描述：具有密码运算功能和自身安全保护功能的 PCI 硬件板卡设备。  
  • 认证依据：  

1）GM/T 0018《密码设备应用接口规范》  

2）GM/T 0028《密码模块安全技术要求》  

3）《PCI 密码卡技术规范》

5、IPSec VPN 产品 / 安全网关  

  • 产品名称：IPSec VPN 产品 / IPSec VPN 安全网关  
  • 功能描述：基于 IPSec 协议，在通信网络中构建安全通道的设备。  
  • 认证依据：  

1）GM/T 0022《IPSec VPN 技术规范》

2）GM/T 0023《IPSec VPN 网关产品规范》

3）GM/T 0028《密码模块安全技术要求》  

6、SSL VPN 产品 / 安全网关  

  • 产品名称：SSL VPN 产品 / SSL VPN 安全网关  
  • 功能描述：基于 SSL/TLS 协议，在通信网络中构建安全通道的设备。  
  • 认证依据：    

  1）GM/T 0024《SSL VPN 技术规范》  

2）GM/T 0025《SSL VPN 网关产品规范》

3）GM/T 0028《密码模块安全技术要求》  

7. 安全认证网关  

  • 产品名称：安全认证网关  
  • 功能描述：采用数字证书为应用系统提供用户管理、身份鉴别、单点登录、传输加密、访问控制和安全审计服务的设备。  
  • 认证依据：  

1）GM/T 0026《安全认证网关产品规范》  

2）GM/T 0028《密码模块安全技术要求》

8、密码键盘  

  • 产品名称：密码键盘  
  • 功能描述：用于保护 PIN 输入安全并对 PIN 进行加密的独立式密码模块。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0049《密码键盘密码检测规范》

9、金融数据密码机  

  • 产品名称：金融数据密码机  
  • 功能描述：用于确保金融数据安全，实现 PIN 加密、MAC 产生与校验、签名验证等密码服务功能的设备。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0045《金融数据密码机技术规范》

10、服务器密码机  

  • 产品名称：服务器密码机  
  • 功能描述：能独立或并行为多个应用实体提供密码运算、密钥管理等功能的设备。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0030《服务器密码机技术规范》

11、签名验签服务器  

  • 产品名称：签名验签服务器  
  • 功能描述：为应用实体提供基于 PKI 体系的数字签名、验证签名等运算功能的服务器。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0029《签名验签服务器技术规范》

12、时间戳服务器  

  • 产品名称：时间戳服务器  
  • 功能描述：基于公钥密码基础设施应用技术体系框架内的时间戳服务相关设备。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0033《时间戳接口规范》

13、安全门禁系统  

  • 产品名称：安全门禁系统  
  • 功能描述：采用密码技术，确定用户身份和用户权限的门禁控制系统。  
  • 认证依据：  

GM/T 0036《采用非接触卡的门禁系统密码应用技术指南》

14、动态令牌 / 动态令牌认证系统  

  • 产品名称：动态令牌 / 动态令牌认证系统  
  • 功能描述：生成并验证动态口令的载体与系统。  
  • 认证依据：  

1）GM/T 0021《动态口令密码应用技术规范》  

2）GM/T 0028《密码模块安全技术要求》（仅适用于动态令牌）

15、安全电子签章系统  

  • 产品名称：安全电子签章系统  
  • 功能描述：提供电子印章管理、电子签章/验章等功能的密码应用系统。  
  • 认证依据：  

1）GM/T 0031《安全电子签章密码技术规范》  

2）GM/T 0055《电子文件密码应用技术规范》

16、电子文件密码应用系统  

  • 产品名称：电子文件密码应用系统  
  • 功能描述：在电子文件全生命周期中提供密码运算、密钥管理等功能的应用系统。  
  • 认证依据：  

GM/T 0055《电子文件密码应用技术规范》

17、可信计算密码支撑平台  

  • 产品名称：可信计算密码支撑平台  
  • 功能描述：为可信计算平台提供完整性、身份可信性和数据安全性密码支持。  
  • 认证依据：  

1）GM/T 0011《可信计算密码支撑平台功能与接口规范》  

2）GM/T 0012《可信计算可信密码模块接口规范》  

3）GM/T 0028《密码模块安全技术要求》  

4）GM/T 0058《可信计算 TCM 服务模块接口规范》

18、证书认证系统 / 证书认证密钥管理系统  

  • 产品名称：证书认证系统 / 证书认证密钥管理系统  
  • 功能描述：用于数字证书全生命周期管理与密钥对全过程管理的系统。  
  • 认证依据：  

GM/T 0034《基于 SM2 密码算法的证书认证系统密码及其相关安全技术规范》

19、对称密钥管理产品  

  • 产品名称：对称密钥管理产品  
  • 功能描述：为密码应用系统生产、分发和管理对称密钥的系统及设备。  
  • 认证依据：  

GM/T 0051《密码设备管理 对称密钥管理技术规范》

20、安全芯片

  • 产品名称：安全芯片  
  • 功能描述：含密码算法、安全功能，可实现密钥管理机制的集成电路芯片。  
  • 认证依据：  

GM/T 0008《安全芯片密码检测准则》

21、电子标签芯片

  • 产品名称：电子标签芯片  
  • 功能描述：采用密码技术，用于射频识别的电子识别信息芯片。  
  • 认证依据：  

GM/T 0035.2《射频识别系统密码应用技术要求 第 2 部分：电子标签芯片密码应用技术要求》

22、其他密码模块

  • 产品名称：其他密码模块  
  • 功能描述：实现密码运算、密钥管理等功能的软件、硬件、固件及其组合。  
  • 认证依据：  

GM/T 0028《密码模块安全技术要求》

//第二批商用密码产品名录

市场监管总局 国家密码管理局于2022年7月14日发布《商用密码产品认证目录（第二批）》，具体如下：

23、可信密码模块  

  • 产品名称：可信密码模块  
  • 功能描述：为可信计算平台提供密码运算功能，具有受保护存储空间的硬件模块。  
  • 认证依据：  

1）GM/T 0012《可信计算可信密码模块接口规范》  

2）GM/T 0028《密码模块安全技术要求》

24、智能 IC 卡密钥管理系统

  • 产品名称：智能 IC 卡密钥管理系统  
  • 功能描述：统一管理智能 IC 卡应用的密钥生命周期，为业务系统提供密钥服务。 
  • 认证依据：  

GM/T 0107《智能 IC 卡密钥管理系统基本技术要求》

25、云服务器密码机

  • 产品名称：云服务器密码机  
  • 功能描述：通过虚拟化技术为多租户提供密码服务的云形态服务器密码机。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0104《云服务器密码机技术规范》

26、随机数发生器

  • 产品名称：随机数发生器（软件 / 硬件）  
  • 功能描述：生成随机二元序列的程序或器件。  
  • 认证依据：  

- 软件：  

  1）GM/T 0028《密码模块安全技术要求》 

  2）GM/T 0103《随机数发生器总体框架》 

  3）GM/T 0105《软件随机数发生器设计指南》  

- 硬件：

  1）GM/T 0028《密码模块安全技术要求》 

  2）GM/T 0078《密码随机数生成模块设计指南》  

  3）GM/T 0103《随机数发生器总体框架》

27、区块链密码模块

  • 产品名称：区块链密码模块  
  • 功能描述：提供用户安全、共识安全、账本保护、隐私保护、身份认证等密码功能。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0111《区块链密码应用技术要求》

28、安全浏览器密码模块

  • 产品名称：安全浏览器密码模块  
  • 功能描述：集成浏览器内核与密码协议逻辑，保障浏览器场景下的密码安全。  
  • 认证依据：  

1）GB/T 38636《信息安全技术 传输层密码协议（TLCP）》  

2）GM/T 0028《密码模块安全技术要求》  

3）GM/T 0086《基于 SM9 标识密码算法的密钥管理系统技术规范》  

4）GM/T 0087《浏览器密码应用接口规范》

//第三批商用密码产品名录

市场监管总局 国家密码管理局于2025年3月27日发布《商用密码产品认证目录（第三批）》，具体如下：

29、基于 SM9 标识密码算法的密钥管理系统  

  • 产品名称：基于 SM9 标识密码算法的密钥管理系统  
  • 功能描述：实现标识密钥注册、生成、管理、发布的信息系统。  
  • 认证依据：  

GM/T 0086《基于 SM9 标识密码算法的密钥管理系统技术规范》

30、PLC 控制器密码模块  

  • 产品名称：PLC 控制器密码模块  
  • 功能描述：为 PLC 控制器提供密钥存储、密码安全服务及与后台安全管理服务器交互功能的设备。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0119《PLC 控制系统及 PLC 控制器密码应用技术规范》

31、DTLCP 密码模块  

  • 产品名称：DTLCP 密码模块  
  • 功能描述：基于数据报传输层密码协议（DTLCP），构建安全通信通道的设备。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0128《数据报传输层密码协议规范》

32、SSH 客户端密码模块 / SSH 服务端密码模块  

  • 产品名称：SSH 客户端密码模块 / SSH 服务端密码模块  
  • 功能描述：基于 SSH 协议，提供安全远程登录和网络服务的设备。  
  • 认证依据：  

1）GM/T 0028《密码模块安全技术要求》  

2）GM/T 0129《SSH 密码协议规范》

参考链接

商用密码32款认证产品、功能及认证依据详细介绍

网页检测 微信登录状态

现在很多网站、应用平台在登录的时候，都支持直接通过微信扫码登录。

最近我发现一个现象：以前需要扫二维码才能登录，而现在，如果你的电脑上已经运行了微信，它能直接检测到，然后点击一个按钮就可以实现登录了。

继续阅读网页检测 微信登录状态

OpenBB的介绍以及如何使用OpenBB助力A股港股的金融数据分析

OpenBB 是一个开源的金融数据平台，旨在为投资者、分析师、研究人员和开发者提供免费、透明且易于使用的金融与宏观经济数据访问接口。它曾被认为是类似于彭博终端（Bloomberg Terminal）的功能性替代品，但完全开放源码，用户可以自由定制和扩展。

在一些文章中将 OpenBB 解释为 Open Bloomberg，这是个误解。尽管它常被视为“开源版彭博终端”，但其名称中的“BB”实际上源自黑莓公司的股票代码，而 OpenBB 的创始人此前曾在黑莓股票上亏损。

继续阅读OpenBB的介绍以及如何使用OpenBB助力A股港股的金融数据分析

macOS双频蓝牙鼠标失联问题

前置条件

  • MacBook Pro 2023-Apple M2 Pro （4能效核、8性能核、32GB内存、2TB磁盘）
  • macOS Sequoia 15.5 
  • Lenovo ThinkLife 静音鼠标无线蓝牙版 WLM210

问题现象

蓝牙鼠标正常配对使用，刚刚开始使用正常的。但是过一阵子不使用蓝牙鼠标，或者鼠标电源调整成关闭状态，或者拔掉电池，大概率连接不上。需要在电脑上手工删除蓝牙连接，然后重新配对。

问题定位

刚开始猜测是鼠标使用的 南孚 TENAVOLTS  锂电池 DC-DC 降压电路释放的信号干扰到了蓝牙通信协议或者电压纹波导致芯片工作异常，在更换为普通的 1.5V 非充电电池之后，问题依旧复现。

无意中点击蓝牙设备列表，发现重新配对之后 Lenovo ThinkLife 的 MAC 地址变化了。这说明两者进行配对的时候使用了动态协商出来的临时 MAC 地址，没有使用设备的真实 MAC 地址。这样诱发一个问题，那就是鼠标需要记住这个动态协商出来的 MAC 地址，然后用这个地址进行通信。这样就能解释为什么拔掉电池多等一会儿，让设备完全放电，再插上电池很容易复现这个问题。因为长时间断电之后，设备上记录的协商 MAC 地址丢失了。

继续阅读macOS双频蓝牙鼠标失联问题

ARG to Rescue: Reuse Variables in Multistage Dockerfile

概要

在参照使用 Ubuntu 22.04使用Podman部署OpenGrok的详细教程 进行 OpenGrok 部署的时候，其中的 Dockerfile 配置了两个独立的镜像来源。恰好这两个镜像来源都需要配置 PIP 国内镜像。于是思考如何在同一个 Dockerfile 存在两个镜像的场景下，如果共用一个变量。

研究了一阵，发现还是通过 ARG 变量实现上述想法。

具体说明参考下面的完整文章。

Introduction

The Docker ecosystem is rich with tools and best practices that streamline containerization. One of these practices is using multistage builds to create lean, efficient containers. However, as your Dockerfiles grow more complex, managing variables and maintaining readability can become a challenge. Enter the ARG instruction—your key to sharing variables across stages in a multistage Dockerfile. In this blog post, we’ll explore how ARG can simplify your Dockerfiles, enhance reusability, and maintain cleaner code.

Why Use Multistage Builds?

Multistage builds in Docker allow you to use multiple FROM statements in a single Dockerfile, creating separate stages that can be used to build a final image. This method is particularly useful for creating lightweight production images, as you can copy only the necessary artifacts from earlier stages. Here’s a quick example to illustrate:

In this simple example, the build stage compiles a Go application, and the production stage creates a minimal image containing only the compiled binary.

The Challenge: Sharing Variables Across Stages

While multistage builds are powerful, they can introduce a common challenge: variable reuse. Suppose you need to use a specific version of an application or a common path across multiple stages. Without a way to share variables, you might end up duplicating code, leading to maintenance headaches and potential errors.

Here’s where ARG (argument) comes into play. The ARG instruction allows you to define variables that can be used throughout your Dockerfile, even across different stages.

Introducing ARG: The Basics

The ARG instruction defines a variable that users can pass at build time to customize the build process. Unlike environment variables (ENV), which are persisted in the image, ARG variables are only available during the build process and do not become part of the final image.

Let’s start with a basic example:

In this example, BASE_IMAGE is an argument that can be overridden when building the Dockerfile. The default value is alpine:3.12, but you could specify a different base image at build time:

Sharing ARG Variables Across Stages

The real power of ARG comes into play with multistage builds. To share ARG variables between stages, you need to redefine the ARG in each stage. Let’s look at a more advanced example:

In this Dockerfile, we define GO_VERSION as an argument at the top. By repeating ARG GO_VERSION in each stage, we make the argument available for use. Notice how the build stage uses GO_VERSION to specify the Go image, and the production stage echoes the Go version used.

Advanced Usage: Combining ARG with Environment Variables

You might find it useful to combine ARG with ENV to set environment variables conditionally based on build arguments. This can further enhance your Dockerfile’s flexibility.

Following example demonstrates the use of ARG and ENV to have a generic Dockerfile for a Turborepo application:

Key Points on Environment Variables in Multistage Builds

  • Environment Variables (ENV):

    • Are specific to the stage where they are defined.
    • Do not persist across stages.
    • If you need an environment variable in multiple stages, you have to redefine it or pass it via ARG.

  • Build Arguments (ARG):

    • Are defined once and can be passed to any stage by redeclaring them.
    • Provide a way to share configuration details like versions or paths between stages.

Debugging ARG Variables

When working with ARG variables, you might run into issues where arguments aren’t passed correctly or variables aren’t set as expected. Here are some tips to help you debug:

  1. Check Build Logs: Use docker build with the --progress=plain flag to get more detailed logs that can help identify where arguments are being used or missed.

  2. Echo Variables: Add RUN echo statements to print the values of your ARG variables during the build process.

  3. Use Default Values: Define sensible default values for your ARG variables to ensure that your build doesn’t fail if arguments are not provided.

Best Practices for Using ARG

  • Define ARG Variables Early: Place ARG instructions at the top of your Dockerfile to make them accessible in all stages.
  • Use Descriptive Names: Choose meaningful names for your arguments to make the Dockerfile easier to understand and maintain.
  • Avoid Secrets in ARG: Never use ARG to pass sensitive data like passwords or API keys, as they can be exposed in the Docker image history.

Conclusion

Using ARG to share variables across stages in a multistage Dockerfile can significantly improve your Docker builds’ maintainability and flexibility. Whether you’re building lightweight production images or dynamically configuring your builds, ARG provides a powerful tool to streamline and enhance your Dockerfile.

参考链接