LibreOffice 是由文档基金会开发的自由及开放源代码的办公室套件。LibreOffice 套件包含文字处理器、电子表格、演示文稿程序、矢量图形编辑器和图表工具、数据库管理程序及创建和编辑数学公式的应用程序。借助 LibreOffice 的命令行接口可以方便地将 office 文件转换成 pdf。如下所示：

$ soffice --convert-to pdf --outdir /tmp /tmp/test.doc

一个完整版本的 LibreOffice 大小为 2 GB，而函数计算运行时缓存目录 /tmp 空间限制为 512M，zip 程序包大小限制为 50M。好在社区已经有项目 aws-lambda-libreoffice 成功的将 libreoffice 移植到 AWS Lambda 平台，基于前人的方法和经验，本人创建了 fc-libreoffice 项目，使 libreoffice 成功的运行在阿里云函数计算平台。fc-libreoffice 在 aws-lambda-libreoffice 的基础上解决了如下问题：

重新编译和裁剪 libreoffice ，使其适配 FC nodejs8 runtime 内置的 gcc 和内核版本；安装运行时缺失的 libssl3 依赖；借助 OSS 运行时下载解压，以绕过 zip 程序包 50M 的限制；制作了一个 example 项目，支持一键部署，快速体验。

本文侧重于记述整个移植过程，记录关键步骤以备忘，也为类似的转换工具移植到函数计算平台提供参考。如果您对于如何快速搭建一个廉价且可扩展的 word 转换 pdf 云服务更感兴趣，可以阅读另一篇文章《五分钟上线——函数计算 Word 转 PDF 云服务》。

准备工作

在开始之前建议找一个台配置较好的 Debain/Ubuntu 机器，libreoffice 编译比较消耗计算资源。并在机器上安装和配置如下工具：

docker-ce 安装方法参考官方安装文档fun 一款函数计算的编排工具，用于快速部署函数计算应用。MacOS 平台可以使用如下方法安装

brew tap vangie/formulabrew install fun

其他平台可以通过 npm 安装

npm install @alicloud/fun -g

ossutil oss 的命令行工具。将其下载并放置到 $PATH 所在目录。编译 libreoffice

我们会采用 fc-docker 提供的 aliyunfc/runtime-nodejs8:build docker 镜像进行编译。fc-docker 提供了一系列的 docker 镜像，这些 docker 镜像环境非常接近函数计算的真实环境。因为我们打算把 libreoffice 跑在 nodejs8 环境中，所以我们选用了 aliyunfc/runtime-nodejs8:build，build 标签镜像相比于其他镜像会多一些构建需要的基础包。

启动一个编译环境

通过如下命令可启动一个用于构建 libreoffice 的容器。

docker run --name libre-builder --rm -v $(pwd):/code -d -t --cap-add=SYS_PTRACE --security-opt seccomp=unconfined aliyunfc/runtime-nodejs8:build bash

上面的命令，我们启动了一个名为 libre-builder 的容器并把当前目录挂载到容器内文件系统的 /code 目录。附加参数 --cap-add=SYS_PTRACE --security-opt seccomp=unconfined 是 cpp 程序编译需要的，否则会报出一些警告。-d 表示以后台 daemon 的方式启动。-t 表示启动 tty，配合后面的 bash 命令是为了卡主容器不退出。而 --rm 表示一旦容器停止了就自动删除容器。

安装编译工具

接下来进入容器安装编译工具

apt-get install -y ccacheapt-get build-dep -y libreoffice

ccache 是一个编译工具，可以加速 gcc 对同一个程序的多次编译。尽管第一次编译会花费长一点的时间，有了ccache，后续的编译将变得非常非常快。

apt-get 的 build-dep 子命令会建立某个要编译软件的环境。具体行为就是把所有依赖的工具和软件包都安装上。

克隆源码

git clone --depth=1 git://anongit.freedesktop.org/libreoffice/core libreofficecd libreoffice

记得加上 --depth=1 参数，因为 libreoffice 项目比较大，进行全量克隆会比较费时间，对于编译来说 git 提交历史没有意义。

配置并编译

# 如果多次编译，该设置可以加速后续编译ccache --max-size 16 G && ccache -s

通过 --disable 参数去掉不需要的模块，以减少最终编译产物的体积。

# the most important part. Run ./autogen.sh --help to see wha each option means./autogen.sh --disable-report-builder --disable-lpsolve --disable-coinmp \ --enable-mergelibs --disable-odk --disable-gtk --disable-cairo-canvas \ --disable-dbus --disable-sdremote --disable-sdremote-bluetooth --disable-gio --disable-randr \ --disable-gstreamer-1-0 --disable-cve-tests --disable-cups --disable-extension-update \ --disable-postgresql-sdbc --disable-lotuswordpro --disable-firebird-sdbc --disable-scripting-beanshell \ --disable-scripting-javascript --disable-largefile --without-helppack-integration \ --without-system-dicts --without-java --disable-gtk3 --disable-dconf --disable-gstreamer-0-10 \ --disable-firebird-sdbc --without-fonts --without-junit --with-theme="no" --disable-evolution2 \ --disable-avahi --without-myspell-dicts --with-galleries="no" \ --disable-kde4 --with-system-expat --with-system-libxml --with-system-nss \ --disable-introspection --without-krb5 --disable-python --disable-pch \ --with-system-openssl --with-system-curl --disable-ooenv --disable-dependency-tracking

开始编译

make

最终的编译结果位于 ./instdir/ 目录下。

精简尺寸

使用 strip 命令去除二进制文件中的符号信息和编译信息

# this will remove ~100 MB of symbols from shared objectsstrip ./instdir/**/*

删除不必要的文件

# remove unneeded stuff for headless moderm -rf ./instdir/share/gallery \ ./instdir/share/config/images_*.zip \ ./instdir/readmes \ ./instdir/CREDITS.fodt \ ./instdir/LICENSE* \ ./instdir/NOTICE

验证

使用如下命令，测试一下编译出来的 soffice 是否能正常将 txt 文件转换成 pdf 文件。

echo "hello world" > a.txt./instdir/program/soffice --headless --invisible --nodefault --nofirststartwizard \ --nolockcheck --nologo --norestore --convert-to pdf --outdir $(pwd) a.txt

打包

# archivetar -zcvf lo.tar.gz instdir

然后使用如下命令将 lo.tar.gz 文件从容器文件系统拷贝到宿主机文件系统。

docker cp libre-builder:/code/libreoffice/lo.tar.gz ./lo.tar.gz

Gzip vs Zopfli vs Brotli

Gzip 、Zopfli 和 Brotli 是三种开源的压缩算法，对于一个 130M 的 chromium 文件，分别采用这三种压缩算法最大 level 的压缩效果是

文件 算法 MiB 压缩比 解压耗时 chromium - 130.62 - - chromium.gz Gzip 44.13 66.22% 0.968s chromium.gz Zopfli 43.00 67.08% 0.935s chromium.br Brotli 33.21 74.58% 0.712s 从上面的结果看 Brotli 算法的效果最优。

由于 aliyunfc/runtime-nodejs8:build 是基于 debain jessie 发行版的。在 debain jessie 上安装 brotli 较为麻烦，所以我们借助 ubuntu 容器安装 brotli 工具，将 tar.gz 格式转为 tar.br 格式。

docker run --name brotli-util --rm -v $(pwd):/root -w /root -d -t ubuntu:18.04 bashdocker exec -t brotli-util apt-get updatedocker exec -t brotli-util apt-get install -y brotlidocker exec -t brotli-util gzip -d lo.tar.gzdocker exec -t brotli-util brotli -q 11 -j -f lo.tar

然后当前目录会多一个 lo.tar.br 文件。

安装依赖

在函数计算 nodejs8 环境中运行 soffice ，需要安装通过 npm 安装 tar.br 的解压依赖包 @shelf/aws-lambda-brotli-unpacker 和 通过 apt-get 安装 libnss3 依赖。先启动一个 nodejs8 的容器，以保证依赖的安装环境和运行时环境是一致的。

docker run --rm --name libreoffice-builder -t -d -v $(pwd):/code --entrypoint /bin/sh aliyunfc/runtime-nodejs8

注意：@shelf/aws-lambda-brotli-unpacker 存在 native binding，所以在开发机 MacOS 上 npm install 打包上传是无法工作。

docker exec -t libreoffice-builder npm install

由于函数计算运行时无法安装全局的 deb 包，所以需要将 deb 和依赖的 deb 包下载下来，再安装到当前工作目录而不是系统目录。当前工作目录下可以随代码一起打包上传。

docker exec -t libreoffice-builder apt-get install -y -d -o=dir::cache=/code libnss3docker exec -t libreoffice-builder bash -c 'for f in $(ls /code/archives/*.deb); do dpkg -x $f $(pwd) ; done;'

libnss3 包含了许多 .so 动态链接库文件，linux 系统下 LD_LIBRARY_PATH 环境变量里的动态链接库才能被找到，而函数计算将代码目录/code 下的 lib 目录默认添加到了 LD_LIBRARY_PATH 中。所以我们写个脚本，把所有安装的 .so 文件软连接到 /code/lib 目录下

docker exec -t libreoffice-builder bash -c "rm -rf /code/archives/; mkdir -p /code/lib;cd /code/lib; find ../usr/lib -type f \( -name '*.so' -o -name '*.chk' \) -exec ln -sf {} . \;"

下载并解压 tar.br

为了使用 这个 lo.tar.br 文件，需要先上传到 OSS

ossutil cp $SCRIPT_DIR/../node_modules/fc-libreoffice/bin/lo.tar.br oss://${OSS_BUCKET}/lo.tar.br \ -i ${ALIBABA_CLOUD_ACCESS_KEY_ID} -k ${ALIBABA_CLOUD_ACCESS_KEY_SECRET} -e oss-${ALIBABA_CLOUD_DEFAULT_REGION}.aliyuncs.com -f

在函数的 initializer 方法中下载。

module.exports.initializer = (context, callback) => { store = new OSS({ region: `oss-${process.env.ALIBABA_CLOUD_DEFAULT_REGION}`, bucket: process.env.OSS_BUCKET, accessKeyId: context.credentials.accessKeyId, accessKeySecret: context.credentials.accessKeySecret, stsToken: context.credentials.securityToken, internal: process.env.OSS_INTERNAL === 'true' }); if (fs.existsSync(binPath) === true) { callback(null, "already downloaded."); return; } co(store.get('lo.tar.br', binPath)).then(function (val) { callback(null, val) }).catch(function (err) { callback(err) });};

然后借助于 @shelf/aws-lambda-brotli-unpacker npm 包解压 lo.tar.br

const {unpack} = require('@shelf/aws-lambda-brotli-unpacker');const {execSync} = require('child_process');const inputPath = path.join(__dirname, '..', 'bin', 'lo.tar.br');const outputPath = '/tmp/instdir/program/soffice';module.exports.handler = async event => { await unpack({inputPath, outputPath}); execSync(`${outputPath} --convert-to pdf --outdir /tmp /tmp/example.docx`);};

fun 部署函数

编写一个 template.yml 文件，将函数计算的配置都写在该文件中，然后使用 fun deploy 命令部署函数。

ROSTemplateFormatVersion: '2015-09-01'Transform: 'Aliyun::Serverless-2018-04-03'Resources: libre-svc: # service name Type: 'Aliyun::Serverless::Service' Properties: Description: 'fc test' Policies:  - AliyunOSSFullAccess libre-fun: # function name Type: 'Aliyun::Serverless::Function' Properties: Handler: index.handler Initializer: index.initializer Runtime: nodejs8 CodeUri: './' Timeout: 60 MemorySize: 640 EnvironmentVariables: ALIBABA_CLOUD_DEFAULT_REGION: ${ALIBABA_CLOUD_DEFAULT_REGION} OSS_BUCKET: ${OSS_BUCKET} OSS_INTERNAL: 'true'

真实场景下，把秘钥和一起变量写在 template.yml 里并不合适。为了做到代码和配置相分离，上面使用了变量占位符 ${ALIBABA_CLOUD_DEFAULT_REGION} 和 ${OSS_BUCKET} 。

然后使用 envsubst 进行替换

SCRIPT_DIR=`dirname -- "$0"`source $SCRIPT_DIR/../.envexport ALIBABA_CLOUD_DEFAULT_REGION OSS_BUCKETenvsubst < $SCRIPT_DIR/../template.yml.tpl > $SCRIPT_DIR/../template.ymlcd $SCRIPT_DIR/../

上面所有的配置都写在了 .env 文件中，dotenv 是社区常见的方案，也有广泛的工具支持。

小结

本文重点介绍了编译 libreoffice 的过程，这也是移植中较为困难的部分。由于 libreoffice 又涉及到 npm 的 native binding 和 apt-get 安装到本地目录的问题，所以在函数计算依赖方面本例也是非常经典的场景。无论是编译还是依赖安装，本文中的步骤都强烈地依赖 fc-docker 镜像，正因为有了该镜像，解决了环境差异问题，大大降低了移植的难度。大文件运行时加载也是函数计算的常见问题，对于转换工具场景中常见的大文件是二进制程序，对于机器学习场景中大文件常是训练模型的数据问题，但是无论是哪一种，采用 OSS 下载解压的方法都是通用的，随着函数计算支持了 NAS，使用 NAS 挂载共享网盘的方式也是一种新的路径。

上文完整的源码可以在 fc-libreoffice 项目中找到。

参考阅读 to Run LibreOffice in AWS Lambda for Dirty-Cheap PDFs at Scale

作者：倚贤