记一次正式环境升级docker服务基础进行版本异常

因为服务的httpd和tomcat基础镜像版本比较旧，漏洞多，需要升级至最新版本。在本地环境和测试环境都是直接将dockerfile中的FROM基础镜像升级至最新：

httpd：由httpd:2.4.52-alpine升级至httpd:2.4.57

tomcat：由4年前的tomcat:last升级至tomcat:9-jdk21-openjdk-slim

但是在正式环境docker容器都启动失败：

其中tomcat报错：canot find /usr/local/tomcat/bin/setclasspath.sh

httd容器报错：线程无权启动

在报错的服务器上使用tomcat基础镜像自定义了一个空容器以便检查容器内部情况：

FROM tomcat:9-jdk21-openjdk-slim
CMD ["/bin/bash", "-c", "while true; do sleep 1; done"]

检查结果发现，报错的文件 /usr/local/tomcat/bin/setclasspath.sh存在，检查启动文件/usr/local/tomcat/bin/catalina.sh，发现了报错的原因是在判断语句

if [ -r "$CATALINA_HOME"/bin/setclasspath.sh ]; then

返回了false导致报错和服务终止。通过ls -l命令检查了一下用户组和文件的权限，发现是root用户、文件权限为-rwxr-xr-x，理论上说docker容器默认就是root用户，继续对setclasspath.sh使用cat命令和sh命令都无异常，但是手动输入

if [ -r /usr/local/tomcat/bin/setclasspath.sh ]; then
    echo "The file is readable"
else
    echo "The file is not readable"
fi

返回的结果就是The file is not readable，证明容器中if -r命令返回结果异常。感觉是基础镜像中的权限命令似乎出现异常，使用--privileged再次启动容器，再次手动输入上述命令，返回The file is readable，结果正常。对http容器，启动时也添加--privileged参数后，启动正常。

因为--privileged参数会增大宿主机的安全风险，所以继续探究更好的解决方案，猜测基础容器的部分命令可能跟宿主机不兼容导致，遂测试多个镜像版本，发现基于更旧系统的tomcat:9.0.80-jdk8-corretto-al2和httpd:2.4.57-bullseye能够满足无--privileged参数正常启动的要求，更加确定了是因为httpd和tomcat中依赖的系统版本差异导致部分基础命令异常的猜测。