Docker踩坑，又长知识了

背景介绍新的批处理功能上线，基于Docker的release。上线后出现Docker批处理生成的文件目录无法被其他应用访问的问题。之前一直在用Docker，但是没有涉及到文件共享，所以还真没注意。经过一系列的调查，终于找到了原因。本文将记录调查过程中用到的技术要点，同时也帮助大家复习。涉及知识点：Docker帮助命令、Linux用户/组id查看、Docker用户指定、Docker启动失败日志查看等现象分析Docker运行项目定时创建文件目录并执行文件生成等操作，但是当其他应用操作时Docker应用生成的目录，将显示“Permissiondenied”错误。查看Docker生成的文件夹权限，是root用户创建的。执行Docker启动脚本明明是普通用户，那为什么生成的文件变成了root用户呢？这涉及到通过Docker执行执行时使用的用户。如果执行Docker命令时没有指定用户，则默认以root用户执行。当然在这个生产环境中是不允许的。问题解决由于更容易找到问题原因，所以记录下问题解决和涉及到的一些Docker命令和Linux操作。查询帮助文档首先我们通过help命令查看Docker的命令参数，以及如何指定执行命令的用户。先尝试docker--help命令，结果并没有找到指定用户的命令参数：$sudodocker--helpUsage:docker[OPTIONS]COMMANDAself-sufficientruntimeforcontainerOptions:--configstringLocationofclientconfigfiles(default"/root/.docker")-c,--contextstring用于连接到守护进程的上下文的名称（覆盖DOCKER_HOSTenvvar和使用“dockercontextuse”设置的默认上下文）-D,--debug启用调试模式-H,--hostlistDaemonsocket(s)toconnectto-l,--log-levelstring设置日志级别("debug"|"info"|"warn"|"error"|"fatal")(默认"info")--tls使用TLS；--tlsverify隐含--tlscacertstring仅由该CA签名的信任证书（默认为“/root/.docker/ca.pem”）--tlscertstringTLS证书文件的路径（默认为“/root/.docker/cert.pem")--tlskey字符串TLS密钥文件的路径（默认为“/root/.docker/key.pem”）--tlsverify使用TLS并验证remote-v,--version打印版本信息并退出后来才知道找的应该是docker的run命令的帮助文档：$sudodockerrun--help...-u,--userstring用户名orUID(format:[:])--usernsstring要使用的用户命名空间--utsstring要使用的UTS命名空间...其中，有用户参数用于指定操作run命令，通过-u可以指定用户和组来执行命令。docker指定用户参考帮助手册整理docker运行命令（伪代码）：$sudodockerrun-itd-utestuser-p8080:8080-v/log/:/logxxx-job:latest在上面的指令中，执行命令的用户是通过-u用户名来指定的。按道理说是可以正常执行，但是在执行过程中抛出如下异常信息：docker:Errorresponsefromdaemon:unabletofindusertestuser:nomatchingentrysinpasswdfile.'虽然当前用户是testuser，docker似乎没有在passwd文件中找到它。这时候Username就直接换成了用户的UID。获取Linux用户UID获取Linux用户UID的方式有两种。方法一：执行命令。获取UID命令：$id-u1002当前用户的UID为1002获取组ID命令：$id-g1002当前用户所属的组ID为1002方法二：查看/etc/passwd获取UID和组ID。执行cat/etc/passwd命令显示/etc/passwd的内容。图片来自网络。在/etc/passwd中找到当前用户对应的UID和组ID。调整Docker命令获取当前用户的UID和组ID后，Docker运行命令修改如下：$sudodockerrun-itd-u1002:1002-p8080:8080-v/log/:/logxxx-job:latestisnormal至此，问题解决，应用可以正常启动。查看Docker日志，但是笔者又遇到了一个问题，就是应用在Docker中的日志。由于之前的错误，默认是由root用户创建的。这时使用testuser启动应用，发现Docker无法启动。原因很简单。应用程序无法将日志写入由root创建的日志文件。检查启动失败时，使用命令查看Docker失败日志：dockerlogs97069f94437b这时候要么备份原日志让系统重新生成日志文件，要么直接修改日志文件权限给testuser。至此，Docker生成的目录权限问题已经解决。总结其实造成上述问题的原因很小，就是少了一个参数。但如果你不经历一件事，你就不会获得智慧。可能很多朋友在使用Docker的过程中可能没有注意到这个问题。问题的排查过程也很有意思。不仅涉及到Docker的操作命令，还涉及到Linux的一些基础知识。知识和技能是在问题发生和解决问题的过程中增长的。