语言
<< 返回文章列表

openGauss 2.0.0 容器镜像来了！

2021年4月9日
李宏达
32

3月31日，openGauss 2.0.0 版本正式上线！openGauss 2.0.0 是 openGauss 社区发布的第一个 Release 版本。2.0.0版本与之前版本保持兼容的同时，也新增了众多特性，特别是在高性能、高安全和智能化的打造上有了更大的突破。

openGauss 是一款开源关系型数据库管理系统，采用木兰宽松许可证v2发行。openGauss 内核源自 PostgreSQL，深度融合华为在数据库领域多年的经验，结合企业级场景需求，持续构建竞争力特性。同时 openGauss 也是一个开源的数据库平台，鼓励社区贡献、合作。

 

云和恩墨紧密跟踪 openGauss 的源码变化，第一时间发布新版本的容器镜像。

 

PART ONE
云和恩墨openGuass镜像的特点

  • 云和恩墨发布的 openGauss 2.0.0 镜像在云端环境、虚拟机环境和容器环境下均使用相同的初始化最佳实践配置，这样当您在应对各种不同需求时会有几乎相同的体验。

  • 云和恩墨会持续发布基于不同 CPU 架构（x86 或者 ARM）的不同操作系统的各种镜像。目前已经支持 x86-64 和 ARM64 两种架构，会根据您获取镜像时运行的机器架构自动判断。

从2.0.0版本开始（包括2.0.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 操作系统中。

 

PART TWO
容器的定义与优势

1、容器基础知识：什么是容器？

容器提供了一种逻辑打包机制，以这种机制打包的应用可以脱离其实际运行的环境。利用这种脱离，不管目标环境是私有数据中心、公有云，还是开发者的个人笔记本电脑，您都可以轻松、一致地部署基于容器的应用。容器化使开发者和 IT 运营团队的关注点泾渭分明——开发者专注于应用逻辑和依赖项，而 IT 运营团队可以专注于部署和管理，不必为具体的软件版本和应用特有的配置等应用细节分心。

之前使用虚拟化环境的用户经常会将容器与虚拟机 (VM) 进行比较。您可能已经熟悉虚拟机的定义：在主机操作系统上运行且以虚拟化途径访问底层硬件的客机操作系统（如 Linux 或 Windows）。与虚拟机相似，容器也让您可以将应用与库和其他依赖项打包，提供独立环境来运行您的软件服务。但是，我们从下方可以看到，两者的相似性仅此而已，因为容器为开发者和 IT 运营团队提供了更加轻型、具有众多优势的运营单元。

2、为什么要使用容器？

与虚拟机的硬件栈虚拟化不同，容器在操作系统级别进行虚拟化，且可以直接在操作系统内核上运行多个容器。也就是说，容器更轻巧：它们共享操作系统内核，启动速度更快，且与启动整个操作系统相比其占用的内存微乎其微。

可用的容器格式有许多。Docker 是一种广受欢迎的开源容器格式。

  • 一致的环境
    容器让开发者可以创建与其他应用相隔离的可预测环境。容器还可以包含应用所需的软件依赖项，比如具体的编程语言运行时版本和其他软件库。从开发者的角度看，无论应用最终部署在什么地方，都可以保证这些条件一致。这一切将转化为生产力的提升：开发者和 IT 运营团队可以减少调试和诊断环境差异所需的时间，将更多的时间用于为用户提供新的功能。而且这也意味着 bug 更少，因为开发者现可在开发和测试环境中做出在生产环境中也适用的假设。

  • 在任何地方运行
    容器几乎能在任何地方运行，极大减轻了开发和部署工作量：在 Linux、Windows 和 Mac 操作系统中；在虚拟机或裸机上；在开发者的机器或本地数据中心的机器上；当然还有在公有云上。而 Docker 容器映像格式广受欢迎，则进一步增强了可移植性。无论您希望在什么地方运行软件，都可以使用容器。

  • 隔离
    容器会在操作系统级别虚拟化 CPU、内存、存储和网络资源，为开发者提供在逻辑上与其他应用相隔离的沙盒化操作系统接口。

  容器的优势 虚拟机的优势
一致的运行时环境 ✔️ ✔️
应用沙盒化 ✔️ ✔️
占用的存储空间少 ✔️  
开销低 ✔️  

  • 从代码到应用

    借助容器，您可以将应用及其依赖项封装为一个可进行版本控制的简洁清单文件，不但能让您团队中的开发者轻松复制您的应用，还可在集群中的机器之间复制。

    软件库将零碎的代码打包在一起，让开发者脱离用户身份验证和会话管理等逻辑；与此类似，容器让您可以将应用整个打包，脱离操作系统、机器，甚至是代码本身。结合基于服务的架构，要求开发者考虑的整体单元就会小许多，因而敏捷性和生产力更高。所有这些都能简化应用的开发、测试、部署和整体管理。

 

PART THREE
openGauss 2.0.0 新增特性
1、采用更小的基础镜像

  • 各版镜像本大小对比

2、New Features

2.0.0版本是 openGauss 社区发布的第一个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

 

PART FOUR
使用示例

  • 拉取镜像

[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

  • 进入容器，测试数据库

[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

 

PART FIVE
基础操作系统镜像的选择迭代

1、CentOS & openEuler

由于 CentOS (202MB)和 openEuler (531MB)本身镜像过于大，并不适用于基础镜像，所以考虑更换基础镜像从而缩减容器镜像大小。还有一个不用 CentOS 的原因是，去年12月8日 Red Hat 宣布，CentOS 8将于2021年底结束，而 CentOS 7也将在其生命周期结束后停止维护，这给 CentOS 后续的发展带来些许不确定性，有待观望。

2、Alpine

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 基础镜像的 openGauss 2.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 架构和基础架构之上。

技术细节：

  • 开始选用的是 Debian 10.0，最终选用的是 Debian 10.9-slim。

  • Debian 加载 UTF-8 的方式：

sed -i 's/^# *\(en_US.UTF-8\)/\1/' /etc/locale.gen && locale-gen

  • Debian 10.9-slim 基础镜像里没有遇到 Ubuntu 20.04和20.10的编译问题，一切顺利。

5、总结

  • 最终采用的基础镜像版本为 ARM Debian 10.9-slim；x86 Ubuntu 18.04。

  • 实际镜像大小并没有比 Alpine 做基础的镜像大，甚至还小了几兆。（由于需要的依赖包安装后的大小是固定的，更小的镜像必然会有更多的依赖。）

 

PART SIX
容器镜像下载地址
END