记一次正式环境升级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中依赖的系统版本差异导致部分基础命令异常的猜测。

你可能感兴趣的:(docker,容器,运维)