docker image

標籤:docker image

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去提供。可以按自己步調去慢慢適應。