背景

新上線一個批處理功能，基于Docker發(fā)布的。上線之后出現(xiàn)一個問題，Docker批處理生成的文件目錄，別的應用程序無法訪問。

之前也在使用Docker，但并未涉及到文件共享的問題，還真沒留意到。經(jīng)過一系列排查，終于找到原因。這篇文章就記錄一下排查過程中使用到的技術點，也幫大家重溫一下。

(相關資料圖)

涉及的知識點：Docker help命令、Linux用戶/組id查看、Docker用戶指定、Docker啟動失敗日志查看等

現(xiàn)象分析

Docker運行的項目定時創(chuàng)建文件目錄并進行文件生成等操作，但當其他應用程序來操作Docker應用生成的目錄時，會提示“Permission denied”錯誤。

查看Docker生成的文件夾權(quán)限，竟然是以root用戶創(chuàng)建的。執(zhí)行Docker的啟動腳本明明是普通用戶，生成的文件怎么就變成了root用戶了？

這里就涉及到通過Docker執(zhí)行執(zhí)行時所使用的用戶了。如果在執(zhí)行Docker執(zhí)行命令時，未指定所使用的用戶，默認以root用戶執(zhí)行。在這生產(chǎn)環(huán)境下當然是不允許的了。

問題解決

既然找到問題的原因解決起來就比較容易了，下面記錄一下解決問題及涉及到的一些Docker命令和Linux操作。

查詢幫助文檔

先來通過help命令查看一下Docker的命令參數(shù)，如何來指定執(zhí)行命令的用戶。

先嘗試了docker --help命令，結(jié)果并未找到指定用戶的命令參數(shù)：

$sudodocker--helpUsage:docker[OPTIONS]COMMANDAself-sufficientruntimeforcontainersOptions:--configstringLocationofclientconfigfiles(default"/root/.docker")-c,--contextstringNameofthecontexttousetoconnecttothedaemon(overridesDOCKER_HOSTenvvaranddefaultcontextsetwith"dockercontextuse")-D,--debugEnabledebugmode-H,--hostlistDaemonsocket(s)toconnectto-l,--log-levelstringSetthelogginglevel("debug"|"info"|"warn"|"error"|"fatal")(default"info")--tlsUseTLS;impliedby--tlsverify--tlscacertstringTrustcertssignedonlybythisCA(default"/root/.docker/ca.pem")--tlscertstringPathtoTLScertificatefile(default"/root/.docker/cert.pem")--tlskeystringPathtoTLSkeyfile(default"/root/.docker/key.pem")--tlsverifyUseTLSandverifytheremote-v,--versionPrintversioninformationandquit

后來才意識到，查找的應該是docker的run命令的幫助文檔：

$sudodockerrun--help...-u,--userstringUsernameorUID(format:[:])--usernsstringUsernamespacetouse--utsstringUTSnamespacetouse...

其中便有指定run命令操作的所屬用戶參數(shù)，通過-u可指定執(zhí)行命令的用戶和組。

docker指定用戶

參照幫助手冊，整理了docker的運行命令（偽代碼）：

$sudodockerrun-itd-utestuser-p8080:8080-v/log/:/logxxx-job:latest

上述指令中通過-u username指定了執(zhí)行命令的用戶，按理說可以正常執(zhí)行的，但執(zhí)行時拋出了以下異常信息：

docker:Errorresponsefromdaemon:unabletofindusertestuser:nomatchingentriesinpasswdfile."

雖然當前用戶是testuser，但docker貌似并未在passwd文件中找到它，此時直接通過用戶的UID來替換Username。

獲得Linux用戶UID

獲得Linux用戶的UID有兩種方法。

方法一：執(zhí)行命令。

獲得UID命令：

$id-u1002

當前用戶的UID便是1002。

獲得組ID命令：

$id-g1002

當前用戶所屬組ID便是1002。

方法二：查看/etc/passwd獲取UID和組ID。

執(zhí)行cat /etc/passwd命令，顯示/etc/passwd中的內(nèi)容。

在/etc/passwd中找到當前用戶后面對應的UID和組ID。

調(diào)整Docker命令

獲得了當前用戶的UID和組ID之后，Docker運行命令修改如下：

$sudodockerrun-itd-u1002:1002-p8080:8080-v/log/:/logxxx-job:latest

正常來說，問題到此便解決了，可正常啟動應用程序。

Docker日志查看

但筆者又遇到另外一個問題，就是Docker中應用的日志，由于之前的失誤默認通過root用戶創(chuàng)建的，此時使用了testuser來啟動應用程序，發(fā)現(xiàn)Docker無法啟動，原因很簡單testuser啟動的應用無法向root創(chuàng)建的日志文件寫日志。

排查啟動失敗時用到了查看Docker失敗日志的命令：

dockerlogs97069f94437b

此時，或?qū)⒃瓉淼娜罩緜浞?，讓系統(tǒng)重新生成日志文件，或直接修改日志文件權(quán)限為testuser即可。

至此，關于Docker生成目錄權(quán)限問題解決完畢。

小結(jié)

其實，導致上面問題的原因很小，就是漏了一個參數(shù)的事。但不經(jīng)一事，不長一智?？赡芎芏嗯笥言谑褂肈ocker的過程中可能都沒留意到這一問題。

而問題的排查過程也很有意思，不僅涉及到了Docker的操作命令，也涉及到了Linux的一些基礎知識，知識和技能就是在出現(xiàn)問題、解決問題的過程中增長的。

在解決了上述問題之后，不僅感慨“純學究式的技術學習，終究還是有缺陷的，必須實踐，必須臨床實踐！”

---

如果你覺得這篇文章不錯，那么，下篇通常會更好。備注“公眾號”添加微信好友（微信號：zhuan2quan）。

▲長按關注”程序新視界“，洞察技術內(nèi)幕

關鍵詞： 當前用戶 執(zhí)行命令 應用程序