从虚拟化到容器化部署脚本整改的采坑记

DLI是Serverless大数据计算服务，其也全面拥抱云原生，因此容器化部署也就成了必然。

在虚拟化部署下我们通常会使用root用户来执行部署过程的一些脚本，使用普通用户来运行程序，即使用su - runtime_user -c 'cmd'方式来运行。但在容器化部署里，容器默认进入用户即为运行程序的普通用户，也就直接执行命令启动即可。因此我们的整改也是简单的去除了su – runtime_user，但出现了如下错误：

从错误中提示文件或目录不存在，可是看过去和我们的修改并没有直接关系，求助广大网友也可知和调用的脚本本身并没有关系，那究竟是什么原因导致的呢？

上图是我们整理安装部署的一个逻辑片段，整理部署逻辑包含在appctl中，主要包含部署操作的几个原子操作。对于某个组件的特殊操作会在扩展的appctl-ext中实现。本次遇到的问题就在appctl-ext中调用special_op.sh时，那我们如何去定位分析这个问题呢？

1.     从原先脚本是运行正常的可知问题并不出在被调用的脚本本身

2.     从错误日志和广大网友的回答中可知是shell脚本在调用时目录或文件被删除了，但appctl-ext中其它语句是执行正确的

其实错误的根因是很明确的，就是目录被删除了，但为什么其它语句或者使用su - runtime_user的方式调用时又没有问题呢？回到我们按照调用的逻辑图里，我们发现在执行xxx.sh里的doSomeOp时发生了目录切换到临时目录，而在appctl里又清理了该临时目录，但从执行逻辑来看还在该临时目录里，因此当调用special_op.sh时因其是类似于重新开启一个进程来执行，此时需要调用getcwd操作，但判断到目录已被删除从而异常退出，而在appctl-ext里的其他语句并没有重新起一个进程来执行操作，因此也就没有触发该bug。而对于su - runtime_user这种方式其环境上下文已经不是当前用户了，因此也不存在该问题。