容器化 | 一文搞定镜像构建方式选型
2023-03-31 11:01:18 时间
作者:安树博 青云科技 PaaS 中间件开发工程师
从事 PaaS 中间件服务(Redis/Memcached 等)开发工作,热衷对 NoSQL 数据库领域内技术的学习与研究
- 官方镜像版本无法满足功能需求
- 镜像内存在的漏洞无法规避
- 传统构建方式镜像体积越来越大
你在使用镜像时是否遇到过以上问题呢?
随着云原生技术的普及,业务负载上容器就越来越普遍。很多企业已经碰到,或正在解决以上这些容器镜像的问题。随着云原生业务覆盖范围越来越大、越来越贴近业务核心,对于镜像安全和可维护等要求也越来越高。
那么构建镜像的方式如何选型就需要根据应用的具体情况来做判断。本文将对目前常见的几种镜像构建方式进行分析,帮您判断。
主流镜像构建方式
传统镜像
不特指某一镜像,本文中代指 Debian/Centos/Ubuntu 等系统下构建的镜像,对于 C/C++ 编写的复杂程序,这是最常用的一种构建方式。
Alpine[1]
Alpine 操作系统是一个面向安全的轻型 Linux 发行版。通过 Alpine 构建的镜像容量非常小,通常 5 MB 左右,包管理机制友好。具有下载速度快,安全性提高等优点。
Distroless[2]
源自于 Google 的镜像,比 Alpine 更精简。除了基础文件其它都不包含,甚至没有 Shell。大多数 Operator 都是基于此系列基础镜像编译。
选型对比
以 Redis 基础镜像构建为例,将三种构建方式在漏洞修复、Shell 支持、C 库、镜像体积等方面进行对比。
Alpine | Distroless | 传统镜像 | 备注 | |
---|---|---|---|---|
漏洞修复 | 快 | 极快 | 一般 | Debian 11 更新到最新 cve 漏洞还有 80 多个,Alpine 和 Distroless 最新版全部修复。 |
Shell | sh | 无 | bash | Distroless 没有 Shell 也就没办法进入镜像去管理和后期维护。 |
C 库 | musl | 可选 | glibc | Alpine 的 C 库是 musl,虽然理论上和 glibc 差异不大, 但 C/C++ 程序在此编译可能会有不同,要进行充分测试。 |
镜像体积 | 约 5MB | 约 2MB | 30MB - 500MB | |
包管理器 | apk | 无 | apt/yum | Alpine 的 apk 包管理器包含软件较少, 只有 1000 多个,且都是精简版,但覆盖了常用软件。 Distroless 没有管理器,需要自己找依赖文件拷贝到镜像里。 传统镜像 apt/yum 软件丰富,但比较臃肿。 |
选型决策树
根据上面总结的三种方式的异同,再根据用户需求抽象成选型决策树,可根据判断做出相应的构建方式。
选型总结
- 如果需要进入镜像管理维护(Shell 工具),不推荐 Distroless 构建;
- 如果需要考虑跨平台并减少非必要依赖库,推荐 Alpine 或 Distroless 构建;
- 如果原应用是基于 C/C++ 编写且很复杂,建议使用传统镜像;
- 如果基于 Go 编写,传统镜像可以排除。
下一期,我们将演示如何使用 Alpine 构建一个 Redis 镜像,尽情期待!
参考引用
- Alpine www.alpinelinux.org
- Distroless https://github.com/GoogleContainerTools/distroless
相关文章
- MySQL 导出 表结构,执行 .sql 文件导入结构或者数据
- mysql体系结构
- 原创|InnoDB事务锁系统及其实现
- DB · 洞见#2|基于LSM-Tree存储的数据库性能改进
- 金融级数据库新坐标:腾讯云TDSQL发布全自研新敏态引擎
- 硬核干货 | 数据异常的本质和价值详解
- 如何处理缓存跟数据库数据不一致?
- Innodb 相较于MyISAM 的优势在哪
- Go---Go网络编程(详细)(一)
- 数据库高并发和高可用方案
- 彻底掌握 MySQL InnoDB 的锁机制
- 直播预告 | PolarDB 开源版在可计算存储上的降本增效原理和实践
- 主从不一致解决方案 && 如何降低主从延迟
- 技术圈高级认证,MySQL高级SQL语句,别藏了,就是你应该知晓的好文 上
- 技术圈高级认证,MySQL高级SQL语句,别藏了,就是你应该知晓的好文 中
- 技术圈高级认证,MySQL高级SQL语句,别藏了,就是你应该知晓的好文 下
- Mybatis 批量将list数据插入到数据库竟然这样处理
- Mac 使用 brew 安装 mysql
- Mysql在项目中相关使用(简单操作数据库)
- 每日一题 ---- 599. 两个列表的最小索引总和[力扣][Go]