Docker踩坑，又漲知識了

背景

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

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

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

現(xiàn)象分析

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

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

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

問題解決

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

查詢幫助文檔

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

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

$ sudo docker --help

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Options:
      --config string      Location of client config files (default "/root/.docker")
  -c, --context string     Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default context set with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default "/root/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default "/root/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/root/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

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

$ sudo docker run --help
...
  -u, --user string                    Username or UID (format: <name|uid>[:<group|gid>])
      --userns string                  User namespace to use
      --uts string                     UTS namespace to use
...

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

docker指定用戶

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

$ sudo docker run -itd -u testuser -p 8080:8080 -v /log/:/log xxx-job:latest

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

docker: Error response from daemon: unable to find user testuser: no matching entries in passwd file.'

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

獲得Linux用戶UID

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

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

獲得UID命令：

$ id -u
1002

當(dāng)前用戶的UID便是1002。

獲得組ID命令：

$ id -g
1002

當(dāng)前用戶所屬組ID便是1002。

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

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

在/etc/passwd中找到當(dāng)前用戶后面對應(yīng)的UID和組ID。

調(diào)整Docker命令

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

$ sudo docker run -itd -u 1002:1002 -p 8080:8080 -v /log/:/log xxx-job:latest

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

Docker日志查看

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

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

docker logs 97069f94437b

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

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

小結(jié)

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

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

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