一、 openGauss
openGauss是一款开源关系型数据库管理系统，采用木兰宽松许可证v2发行。openGauss内核源自PostgreSQL，深度融合华为在数据库领域多年的经验，结合企业级场景需求，持续构建竞争力特性。同时openGauss也是一个开源的数据库平台，鼓励社区贡献、合作。
官网地址 https://opengauss.org/zh/
社区地址 https://gitee.com/opengauss/openGauss-server
二、云和恩墨openGuass镜像的特点
- 云和恩墨会最紧密跟踪openGauss的源码变化，第一时间发布镜像的新版本。
- 云和恩墨的云端数据库，虚拟机数据库以及容器版本数据库均会使用同样的初始化最佳实践配置，这样当您在应对各种不同需求时会有几乎相同的体验。
- 云和恩墨会持续发布不同CPU架构（x86或者ARM）之上，不同操作系统的各种镜像
目前已经支持x86-64和ARM64两种架构，会根据您获取镜像时运行的机器架构自动判断。
从2.0版本开始（包括2.0版本）
- x86-64架构的openGuass运行在 Ubuntu 18.04 操作系统中
- ARM64架构的openGauss运行在 Debian 10 操作系统中
在1.1.0版本之前（包括1.1.0版本）
- x86-64架构的openGuass运行在 CentOS 7.6 操作系统中
- ARM64架构的openGauss运行在 openEuler 20.03 LTS 操作系统中
三、容器的定义与优势
1、容器基础知识：什么是容器？
容器提供了一种逻辑打包机制，以这种机制打包的应用可以脱离其实际运行的环境。利用这种脱离，不管目标环境是私有数据中心、公有云，还是开发者的个人笔记本电脑，您都可以轻松、一致地部署基于容器的应用。容器化使开发者和 IT 运营团队的关注点泾渭分明 - 开发者专注于应用逻辑和依赖项，而 IT 运营团队可以专注于部署和管理，不必为具体的软件版本和应用特有的配置等应用细节分心。
之前使用虚拟化环境的用户经常会将容器与虚拟机 (VM) 进行比较。您可能已经熟悉虚拟机的定义：在主机操作系统上运行且以虚拟化途径访问底层硬件的客机操作系统（如 Linux 或 Windows）。与虚拟机相似，容器也让您可以将应用与库和其他依赖项打包，提供独立环境来运行您的软件服务。但是，我们从下方可以看到，两者的相似性仅此而已，因为容器为开发者和 IT 运营团队提供了更加轻型、具有众多优势的运营单元。
2、为什么要使用容器？
与虚拟机的硬件栈虚拟化不同，容器在操作系统级别进行虚拟化，且可以直接在操作系统内核上运行多个容器。也就是说，容器更轻巧：它们共享操作系统内核，启动速度更快，且与启动整个操作系统相比其占用的内存微乎其微。
可用的容器格式有许多。Docker 是一种广受欢迎的开源容器格式。
- 一致的环境
容器让开发者可以创建与其他应用相隔离的可预测环境。容器还可以包含应用所需的软件依赖项，比如具体的编程语言运行时版本和其他软件库。从开发者的角度看，无论应用最终部署在什么地方，都可以保证这些条件一致。这一切将转化为生产力的提升：开发者和 IT 运营团队可以减少调试和诊断环境差异所需的时间，将更多的时间用于为用户提供新的功能。而且这也意味着 bug 更少，因为开发者现可在开发和测试环境中做出在生产环境中也适用的假设。 - 在任何地方运行
容器几乎能在任何地方运行，极大减轻了开发和部署工作量：在 Linux、Windows 和 Mac 操作系统中；在虚拟机或裸机上；在开发者的机器或本地数据中心的机器上；当然还有在公有云上。而 Docker 容器映像格式广受欢迎，则进一步增强了可移植性。无论您希望在什么地方运行软件，都可以使用容器。 - 隔离
容器会在操作系统级别虚拟化 CPU、内存、存储和网络资源，为开发者提供在逻辑上与其他应用相隔离的沙盒化操作系统接口。
| 容器的优势 | 虚拟机的优势 | |
| 一致的运行时环境 | ✔️ | ✔️ |
| 应用沙盒化 | ✔️ | ✔️ |
| 占用的存储空间少 | ✔️ | |
| 开销低 | ✔️ |
- 从代码到应用
借助容器，您可以将应用及其依赖项封装为一个可进行版本控制的简洁清单文件，不但能让您团队中的开发者轻松复制您的应用，还可在集群中的机器之间复制。
软件库将零碎的代码打包在一起，让开发者脱离用户身份验证和会话管理等逻辑；与此类似，容器让您可以将应用整个打包，脱离操作系统、机器，甚至是代码本身。结合基于服务的架构，要求开发者考虑的整体单元就会小许多，因而敏捷性和生产力更高。所有这些都能简化应用的开发、测试、部署和整体管理。
四、openGauss 2.0.0 增加特性
1、采用更小的基础镜像
- 各版镜像本大小对比
2、New Features
本版本是openGauss 2.0.0 Release版本，在1.1.0版本功能的基础上，新增特性如下：
- 支持延迟备库
相对主机，备机可以延迟一段指定的时间后再回放XLOG记录。 - 备机支持逻辑复制
支持备机逻辑解码，可以减少主机的压力。 - 扩容工具功能增强
优化了扩容工具，支持不停服在线扩容，同时也支持扩容备机或级联备。 - 灰度升级
优化升级工具，增加灰度升级能力，支持业务在线升级。目前仅支持从1.1.0版本到2.0.0版本进行灰度升级。 - 备机IO写放大优化
优化备机IO，平滑备机检查点刷盘的IO量，解决备机IO量大影响查询性能问题。 - WDR诊断报告增加数据库运行指标
新增"Effective CPU"、“WalWrite NoWait”、“Soft Parse”、"Non-Parse CPU"四个数据库运行指标。 - Data Studio客户端工具特性Data Studio针对openGauss内核的多个特性提供了支持，具体如下：
- 增加pldebugger调试功能；
- 增加pldebugger调试功能的回滚，在使用Data Studio调试前增加选项来保证调试函数在修改完数据后回退；
- 支持xml和serial类型，表中增加列，列的类型支持xml和serial(big|normal|small)类型；
- 支持在Data Studio中创建和展示外表对象；
- 支持列存表的partial_cluster_key约束；
- 全局临时表支持DDL的展示和导出；
- 创建分区表支持LOCAL和GLOBAL标记；
- 增加MOT表的展示；
3、容器默认值添加
- 默认支持en_US.UTF-8
- 默认支持PG
安装命令
eval 'gs_initdb --pwfile=<(echo "$GS_PASSWORD") --nodename=$GS_NODENAME --encoding=UTF-8 --locale=en_US.UTF-8 --dbcompatibility=PG -D $PGDATA'
–encoding --locale
- 如果不指定此参数，则使用系统默认区域的编码格式。系统默认区域和编码格式可以使用locale命令查看。
omm@linux:~> locale|grep LC_CTYPE LC_CTYPE="en_US.UTF-8"
–dbcompatibility
- 指定兼容的数据库的类型，取值范围：A、B、C、PG。分别表示兼容O、MY、TD和POSTGRES。默认为A。
- 具体可参考官方文档，工具参考->系统内部使用工具-> gs_initdb
五、使用示例
- 拉取镜像
[root@ecs-x86-001 ~]# docker pull enmotech/opengauss:latest
- 启动容器
[root@ecs-x86-001 ~]# docker run --name test --privileged=true -d -e GS_PASSWORD=Enmo@123 enmotech/opengauss:latest f4df3611af7b2552e0adbd7bd3742c7eda385a0ab7eb63027d84a4116cd7053d
053d
- 进入容器，测试数据库。
[root@ecs-x86-001 ~]# docker exec -it test bash omm@f4df3611af7b:/$ gsql -d postgres -p5432 -r failed to connect Unknown:5432. omm@f4df3611af7b:/$ gsql -d postgres -p5432 -r gsql ((openGauss 2.0.0 build 78689da9) compiled at 2021-03-31 21:04:03 commit 0 last mr ) Non-SSL connection (SSL connection is recommended when requiring high-security) Type "help" for help. postgres=# \copyright GaussDB Kernel Database Management System Copyright (c) Huawei Technologies Co., Ltd. 2018. All rights reserved.
- 查看日志
[root@ecs-x86-001 ~]# docker logs test
六、编译过程中遇到的技术细节
1、CentOS,openEuler
由于CentOS（202MB），和openEuler（531MB）本身镜像过于大，并不适用于基础镜像，所以考虑换基础镜像从而缩减容器镜像大小。
还有一个不用CentOS的原因是CentOS被红帽收购后，后续会绝版。
CentOS Project shifts focus to CentOS Stream
2、alpline
Alpine 操作系统是一个面向安全的轻型 Linux 发行版。它不同于通常 Linux 发行版，Alpine 采用了 musl libc 和 busybox 以减小系统的体积和运行时资源消耗，但功能上比 busybox 又完善的多，因此得到开源社区越来越多的青睐。在保持瘦身的同时，Alpine 还提供了自己的包管理工具 apk，可以通过 https://pkgs.alpinelinux.org/packages 网站上查询包信息，也可以直接通过 apk 命令直接查询和安装各种软件。
技术细节
- 由于安装包管理方式的差异，apk并没有很好的对应yum的安装包，解决办法是拷贝相应的依赖文件进行处理（docker cp）
- 将apk替换成国内源可以加快构建速度，需要安装的系统包有apk add bash shadow libaio
echo "http://mirrors.aliyun.com/alpine/v3.13/main/" > /etc/apk/repositories && \ echo "http://mirrors.aliyun.com/alpine/v3.13/community/" >> /etc/apk/repositorie
- x86相关依赖（libtinfo.so.5，libncurses.so.5，libkeyutils.so.1，libreadline.so.6，liblzma.so.5，glibc-2.33-r0.apk，glibc-bin-2.33-r0.apk，glibc-i18n-2.33-r0.apk）
- arm相关依赖（libreadline.so.7，libcrypt.so.1，libtinfo.so.6,ld-linux-aarch64.so.1,libncurses.so.6,libkeyutils.so.1,libnuma.so.1,glibc-2.30-r0.apk,glibc-bin-2.30-r0.apk,glibc-i18n-2.30-r0.apk）
- glibc依赖包非常不好找，地址留存。glibc相关https://github.com/jvasileff/alpine-pkg-glibc-armhf
- 由于平台兼容性或者依赖处理方式或者其他问题，安装好的openGauss会有符号表的错误（实际并未测试出bug，或者是未触发），所以考虑换其他镜像。
如下
3、Ubuntu
技术细节
- 和openGauss研发团队人员沟通有计划支持Ubuntu系统，故采用Ubuntu 18.04作为基础镜像。
- 解决相关依赖x86架构下的基于Ubuntu基础镜像的openGauss2.0.0可以正常构建并未出现符号表问题。
- apt又是一种安装包管理方式，不同于apk，yum。 rm -rf 清理缓存进一步压缩镜像大小。
apt-get update && apt-get install -y \ libaio-dev \ libkeyutils-dev \ locales \ libreadline-dev && \ rm -rf /var/lib/apt/lists/*;
- Ubuntu加载UTF-8的方式
locale-gen en_US.UTF-8
- 采取类似的方式在Ubuntu 18.04编译arm版本时，openGauss arm版本依赖2.28而本机是2.27,由于升级glibc会引入gcc等组件进一步扩大了镜像大小，考虑到镜像大小和复杂度问题，打算换一个高版本的基础镜像。
ldd (Ubuntu GLIBC 2.27-3ubuntu1.4) 2.27，
- 采用20.04，20.10基础镜像build的时候会报如下错误，尝试过重启docker服务，重启主机，升级docker版本均未解决问题，一般这种报错都是在run容器阶段bash或者sh的问题，现在还不明确是使用的方式问题还是官方镜像有bug，同样的dockerfile在18.04是没问题的。
OCI runtime create failed: container_linux.go:318: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown
- 18.10版本并非是一个LTS版本且已经过期，并未找到相关的apt仓库。
- 在ARM架构上，Ubuntu在上述的测试里遇到了这些问题，因此开始尝试使用Debian。
4、debian
Ubuntu建立在Debian架构和基础架构之上。
技术细节
- 开始选用的是debian10.0，最终选用的是debian:10.9-slim。
- debian加载UTF-8的方式
sed -i 's/^# *\(en_US.UTF-8\)/\1/' /etc/locale.gen && locale-gen
-gen
- Debian 10.9-slim 基础镜像里没有遇到Ubuntu20.04，和20.10的编译问题，一切顺利。
5、总结
- 最终采用的基础镜像版本为arm debian:10.9-slim,x86 Ubuntu 18.04。
- 实际镜像大小并没有比apline做基础镜像大，甚至还小了几兆。（由于需要的依赖包安装后的大小是固定的，更小的镜像必然会有更多的依赖）
