docker image

標籤：docker image

Docker 中的非管理員用户 Docker non-root user

潮流特區
MacauYeah ・2025-03-14

Container USER為何重要 在制作Docker Image的過程中，有時會接觸到 USER 這個設定。這事關到最後的 Docker Container內部運行的那個 user 到底會有什麼權限。大家也要知道，Docker Container 其實也只是一個 Linux 上的程序，也就是如果Container內權限過大，也有機會從 Container 內部存取到 Host上的資料。 一般情況下，Docker Image 預設的 USER 就是 root，最基礎的base image都是一樣。而我們想換，其實也相當簡單，就像Linux上起User一樣，只要經指令RUN adduser xxx 或RUN useradd xxx 也可以在 Docker Image 中創建帳號和 home 資料夾，之後就隨時經USER xxx來切換 實際上是不是這麼簡單? 如果你將要Container中執行的程序，是一個binary，平常你在Linux中也是以 non-root 方式執行，那麼是的，就是那麼簡單。例如你執行系統中的java, node, python，原本在Linux中就已經是誰都可以，那麼你的docker container 也應該沒有難度。 但如果原本的安裝包，預設是由system service來啟動，我們就要花點力氣，看看那個service是怎樣呼叫binary的，然後就一步一步模擬它的做法。例如筆者有打包的codeserver，預設是system service啟動，但它也有提共binary的執行方法，安定好home資料夾後，我們也可以手動啟動。 泛生之檔案權限問題 上述binary的情境之所以簡單，是因為大部份情況下，我們都只對於container 內部運行考慮即可，因為預設投產情況下的運作模式，都是隨時起、隨時刪、隨時砍掉重練，只要container內部運作可以自給自足，就可以了。Docker Swarm的運作也是如此，所以它不預期有的持久化資料權限的問題。 而持久化資料權限的問題，其實早在單個Linux伺服器就已經存在。同一個伺服器中，不同process就有不同的UID，當他們需要共同讀/寫某些檔案，就會設定多人權限。同理，當多個Container要共同檔案，也是同樣問題。在討論共享檔案之前，我們先看看預設 Docker Storage Mount 會給我們什麼權限。 如果是bind mount，bind mount的權限預設會是Host內的檔案或者資料夾的權限。 如果Host是root，container內是non-root，container有機會無法讀寫bind mount內的檔案。 留意權限設置就可以解決問題 如果Host是non-root，但container 內是root，從container內生成的檔案，Host的non-root user就無法使用。 Host是non-root的話就一定無解，Host至少有sudo權限，臨時變成管理員，去修正問題。 如果host和container也是non-root，但UID不夾，其實也不能交換使用。 跟上述一樣，最後要靠sudo來解決問題。 如果host和container也是root，就沒有權限問題，但就有安全性的風險。 如果是volume mount，就還是看看 mount path 是docker image layer中現有的 path還是新起的path 大部份手動建立的named volume都是root 經docker compose起的named volume滿足以下條件的話，將會是non-root。 docker image 中的已有該path存在。 named volume未存在，docker compose會把對應path的內容在初次建立時抄到named volume 中。 例如ubuntu:24.04中的/home/ubuntu，存在於docker image中，它的擁有者就是UID 1000，我們經docker compose HOME_VOLUME:/home/ubuntu，在HOME_VOLUME建立時，就會是UID 1000。但如果是 NOT_EXISTS:/home/ubuntu/somethingNotExists，那麼NOT_EXISTS建立時，也會是root 上述討論的Storage mount是集中在單機情況下，使用HOST OS的本地儲存。若現在的場境是多機共享的share storage，就會更麻煩，還要看看那個share storage本身的屬性。例如常見的Linux NFS，其實有指定的權限，跟NFS的Login權限有關，如果你的process本身對檔案權限很敏感，就請先不要挑戰NFS(例如postgresql)。 Rootless mode - Rootless 模式 Rootless 模式指的是在Host中，執行Container的使用者，不需要是管理員，筆者就常用於開發環境中。投產環境中反而沒有聽過這樣的討論，因為投產環境很少可以讓非管理員去執行這麼重要的環境管理。 雖然只是開發環境，但這像前述的bind mount討論中，如果Host是non-root，但container 內是root，又或是兩者non-root，但UID不夾，也會出現權限問題。無腦的將host user加入docker group，只可以讓非管理員可以運行docker，但解決不了權限問題。 真正有條件解決的，可能就會向linux subgroup的方式發展。暫時筆者用得比較順的rootless mode，可以無腦用的，不是docker，是podman。有興趣的朋友可以經podman官網看看教學，它給筆者的感覺就像是自動轉換UID。 podman rootless mode 想看更多 筆者已經將過去的文章重新整理成gitbook，有興趣睇更多的讀者，可以來筆者的gitbook再翻一翻 https://macauyeah.github.io/AProgrammerPrepares/

Docker 來源掃瞄 - Docker Image Scan

潮流特區
MacauYeah ・2024-12-19

當網安要求越來越高時，我們也要留心 docker image 的來源是不是有漏洞問題。 docker hub 本身就已經有一些安全掃瞄報告，以 nginx 的 1.27.3 版本為例， docker hub nginx 1.27.3 ， docker hub 已經列出相當多的CVE漏洞。 不過對於不公開的 docker image ，安全描瞄可是要收費的。作為小團隊，可能想先尋求一些簡單的免費方案。如果你想同樣的需求，可能Trivy會幫到你。 Trivy Trivy 是一個用於描瞄軟件版本依賴或設定檔是否引用到一些有漏洞問題的軟件，它也能檢測 docker image 是否有漏洞或錯誤設定的問題。而且更好的是， Trivy 本身亦有 Docker Image 版本，我們就不用煩惱怎樣弄一個 Trivy 的執行環境，只要可以運行 docker ，有網路就可以了。但使用 Docker Image 版的 Trivy 有一個額外要求，就是它要有主機上的 docker.sock 權限。 描瞄的指令如下，其中 docker.sock 就是為了讓 containers 內部的程式可以存取主機的 docker daemon , .cache 則是為了方便暫在下載資源。 上面故意用 nginx 的兩個同版本號不同平台的 docker image，其實就是為了引出一些潛在問題。nginx 預設是使用的debain OS的，在筆者寫文章的當下，已經更新到最近的 image ，但始終有一大部份可能的漏洞。反觀 alpine OS 版本，就找不到這麼多問題。 這是因為 alpine 預設安裝的依賴較少，所以找到的漏洞也少。正所謂，做多錯多，唔做唔錯（大誤）。這其實有好有不好，因為在發生問題時，在 alpine 下可能連基本的除錯工具都沒有。除非大家有完整測試，或者對 alpine 有相當的認識，你才會選擇一個非官方預設的版本。但就以事論事，引用較少的依賴，長久之下的確是不會有那麼多隱患。大家如果有條件，也可以試試 alpine 或其他版本。 前一節我們可以看到，Trivy需要經過 socket 的方式才能存取主機上的 container daemon 操作權。但 podman 作為一個不主張 daemon (daemon less)，亦主張不需要 root (rootless)，那麼它該怎樣執行？ 其實podman也有user層面上的 socket，而且 trivy 也有對應的方式去轉用第三方 socket (有點像使用遠端主機 socket，但官方並未宣佈正式支援遠端的方式。) 具體使用方式，筆者亦已在 steam deck 上測試，使用方式如下。不過因為 steam deck 預設沒有 root，筆者就省略 cache 指令，免得之後要有權限問題要手動清理。 Ref Podman socket activation Trivy: Support for rootless podman

Docker Tag 命名

潮流特區
MacauYeah ・2024-10-24

一般來講，同一個docker image會提供多個不同的版本，每個版本會附予不同的tag，以作標識。但以docker image的維護者來講，它的tag通常代表的是自己程式的版本號。不過這個版本號卻存在很多變數，就讓筆者好好地逐一說明。 程式的版本號 在沒有Docker的年代，其實所有軟件在發佈時，都會標示版本號，方便使用方明確追蹤問題，自行選擇升級、降級以解決相容性問題。大家要重現問題，也能清清楚地重現。所以docker image的tag，在某程度，都是代表發佈自己的程式版本號。但以前的年代，軟件底層的依賴，例如OS層面的共享程式庫，則不在發佈的管控中，所以過去的程式，在跨電腦安裝時，都會出現缺少某些共享庫的問題。而使用了Docker後，image以內的共享庫的都會在打包的那一刻固定和發佈，就不會有漏的問題。 庫更新，怎麼辦 上面說到image可以打包共享庫，但問題是共享庫也會有安全性更新問題，那麼對docker image的維護者來講，它自己的tag又該如何命名？ 因為庫的量可大可少，所以一般來說，都不可能完全把各個庫的版本號寫在自己的tag上。退而求其次，就是用"版本號+日期"，庫的細版本號，就存在原始碼當中。Ubuntu 就是這樣的例子。 不過"版本號+日期"的命名方式真的方便嗎？每次下遊用戶想更新去最近版本，都要自己找一次最近的日期。這樣對很多用戶來講都不夠方便。所以docker又提供了一個重tag的功能。例如ubuntu:noble，在早些時候指著noble-20240904.1，然後過幾天，又指向更新的noble-20241009。更常見的是latest，每次image都預設會存在，docker也希望大家會定期更新這個tag，讓大家可以更易地找到最新版本。 註: 這跟git tag有所不同，git tag並不預期會變的。當協作者收到tag後，那怕上遊刻意更新tag指針，協作者沒有刪除原tag之前，都不會知道tag更新去了哪裏。 我們該如何選 在發佈方和引用方來講，引用時可以明確使用唯一的"版本號+日期"，對穩定性來講是有意義的。不過多多少少，會產生額外的時間成本。發佈方來說，就是多用了一些儲存空間，方便引用方可以隨時找到舊(庫)版本。而引用方，就要手動修改引用號，作為驗收依據，自動更新的難度比較大。 但對於自動更新要求比較大的情況下，可能就是使用latest或者會隨時更新的share tag(共用tag)比較實際。但我們也依然要定一些方式去版本更新記錄，例如：同時使用 beta latest archive 每日自動更新beta，只有所有測試都通過時，才把archive指向現在的latest，再把latest指向現在的beta。這樣做的好處是，核心的docker stack檔案改變的機會較少，也可以免除docker swarm做太細緻的權限管理。

Docker Image打包建議

潮流特區
MacauYeah ・2024-07-10

之前筆者有分享過兩個不同的Docker Image打包方式 App直接打包成Image 只把底層程式打包在Image中(例如Tomcat)，再用Docker Volume的方式讓Container可以起動App。 筆者就兩種方式做了一個條列式的對比。詳見連結 https://macauyeah.github.io/AProgrammerPrepares/VMDockerNotes/DeployDockerClusterCN.html 因為兩種方式筆者都有實作過，也算用了很段時間，所以也有一些實際經驗可以分享。 如果大家上正式的Docker課程，Docker導師通常會推薦為每個App打包成獨立Image，因為底層程式的Overhead通常不大，例如底層程式是Tomcat、Apache、Nignx這類網頁伺服器，重量級的開銷並不是因為多幾個Web Engine的分身造成，通常都是因為業務本身。但如果你講的底層程式是資料庫等的大型程式，才可能會有明顯的差異。 但實務上的建議，就是必需考慮自身的經驗，到底那個方案自己比較有把握。獨立打包App，在正式環境也需要考慮跟蹤問題的情況，多個不同App要溝通，也是了解Container網絡。如果打包底層程式，所有App都可以當成是本機下運行，更有信心追蹤問題，也是一個很好的出發點，到了有需要彈性改變不同App的需要，才轉向獨立打包的做法。 筆者最初也是走這個打包底層程式的方向，到了自己有信心試用Docker Swarm，才走向獨立打包的做法。筆者親身經驗，因為到了Docker Swarm，網段會變得暴增，這跟公司現有的內部網絡相衝的機會就會變多。在Swarm起立初時，筆者並沒有意識到這件事，所以當初排查問題，也花了一些時間才知道要向網段衝突上著手。 另一個出自Docker導師實務上的建議，就是正式環境中不要做用Docker compose，應該使用Docker Swarm。那怕Swarm只有一個節點，也應該用Swarm，導師的主要理據是Swarm有Rolling Update （滾動更新）的機制。同一個node也可以有多個分身，每個分身輪流更新，就不會出現大中斷的情況。筆者就自身經驗，Tomcat可以同時容納一個App的多個版本，Nginx也有Failover（故障轉移）等，如果你很熟這些功能，不一定要需要靠Swarm去提供。可以按自己步調去慢慢適應。