工程安装与部署中处理环境变量的最佳实践

文章目录

将环境变量统一至于一个shell脚本文件
使用find+sed进行查找替换

长久以来，对环境相关变量的处理一直是应用程序在构建部署时普遍遇到的问题，对于这些环境相关变量的替换一般会选择在下面两个环节中的一个完成：

编译期
安装部署期

就编译期的环境变量替换，Maven的Profile机制可算是一个非常经典的实现了，也是当之无愧的最佳实践，其他构建工具也有类似的功能，这种依赖编译工具在编译时将面向特定环境的变量进行替换的作法可以满足大多数的项目的需求。

但是在编译期处理也有一些“不便之处”：

用户必须检出源代码进行编译才能得到适合自己环境的安装包，操作起来比较麻烦
为了完成编译，用户还必须先行安装编译工具，编译过程中还需要下载依赖包，费力耗时
用户必须熟悉工程使用的构建工具，才能准确找到修改配置环境变量的地方

对于一个开发团队来说，可以通过文档和培训快速掌握相关技能，但如果应用是开源项目，对公共开放的话，从编译开始构建应用是不够友好的，侧面提高了使用项目的技术门槛，不利于于项目的应用和推广。所以，即使应用程序已经在编译期实现了变量替换，为程序安装包提供安装部署期的环境变量替换依然是非常值得一做的，这可以帮助用户跳过源代码编译，直接在本地安装。

接下来我们就重点讨论一下如何在安装部署期进行环境变量的替换，这里有两点最佳实践：

将环境变量统一至于一个shell脚本文件

我们应该把环境变量统一提取到一个独立的shell脚本中，可取名为env.sh或constants.sh，其他脚本通过source命令引入该脚本，脚本中的变量定义使用如下格式：

APP_HOST="${app.host}"
APP_USER="${app.user}"

对于变量实际取值的替换，可以由两种方式独立实现：

在编译期，借助Maven的Profile机制完成变量替换
在安装部署期，可以在安装脚本（如install.sh一类的shell脚本）中通过sed命令进行变量替换

这一做法的好处是：两种变量替换方式彼此独立，互不干扰，灵活满足不同情形下的环境变量的替换问题。

使用find+sed进行查找替换

上述作法已经可以满足绝大多数应用了，但是不排除有一些环境变量不能或不方便提取到shell中的情况，举个例子：在大数据项目中会包含数量庞大的sql文件，这些sql会频繁地引用hdfs或s3上的路径，这些路径都是环境相关的，取决于用户分配的目录，例如下面的sql:

create table if not exists user(`id` bigint,`name` string,...
)
partitioned by (year string, month string)
stored as parquet
location 's3://${data.bucket}/user/';

这些sql中大量使用${data.bucket}这些的Maven变量，以期望在编译期进行变量替换，由于这是sql文件，不能或不方便像shell那样在一个统一的地方定义这些变量。

类似这样的情形，我们可以使用find+sed命令，大批量地进行查找和替换，例如下面的命令：

find "/my-project-home/sql/" -type f -name "*.sql" -print0 | xargs -0 sed -i "s|s3://[a-zA-Z0-9_-]*/|s3://$DATA_BUCKET/|g"

将可以将类似s3://my-data-bucket/user/一类的路径替换为变量DATA_BUCKET的值。

关于作者：耿立超，架构师，15年IT系统开发和架构经验，对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验，热衷函数式编程。对Hadoop/Spark 生态系统有深入和广泛的了解，参与过Hadoop商业发行版的开发，曾带领团队建设过数个完备的企业数据平台，个人技术博客：https://laurence.blog.csdn.net/ 作者著有《大数据平台架构与原型实现：数据中台建设实战》一书，该书已在京东和当当上线。