一千萬個為什麽

搜索

耦合docker註冊表和源代碼控制



將docker映像註冊表與SCM服務(如bitbucket)耦合的最佳實踐(如果有的話)是什麽?

我知道docker註冊表可以存在於神器中,但我怎麽能確保兩者盡可能緊密耦合?

例如,我擔心如果沒有開發人員的盡職調查,註冊表中的最新Docker鏡像將不會反映SCM中Dockerfile的當前狀態,反之亦然。此外,我們必須始終追溯到註冊表中任何圖像的基礎Dockerfile(我們制作)。

轉載註明原文: 耦合docker註冊表和源代碼控制

一共有 2 個回答:

我能夠在這裏得到答案 forums.docker.com 信用去dmaze。

建立某種自動構建系統(在當前時尚術語中“持續集成”)。 Docker在這一點上已經足夠主流,任何基於雲或本地安裝的CI系統都可以做到這一點。

在Dockerfile中,使用LABEL記錄構建的源。這可能包括來自分布式源代碼控制(git,Mercurial)的提交哈希,相關的分支名稱,任何版本標記(如果存在),以及可能的詳細信息,例如上次提交的時間戳。 docker history和docker inspect應該能夠顯示這些。

當您使用docker推送圖片時,使用提交哈希並將分支名稱作為“版本”部分推送至少兩次(quay.io/mycorp/imagename:123abc7,quay.io/mycorp/imagename:dmaze-test )。如果發布標簽隨時可用,CI系統也應該使用這些標簽推送圖像。

當然,確保Dockerfile已提交到源代碼控制,並嘗試使用穩定路徑來獲取可能存在的任何外部依賴項。

現在你可以兩種方式:給定一個任意提交,如果你的CI系統構建它,你可以運行它建立的鏡像;如果你有一張圖片,你可以找到源代碼中的確切位置,git checkout或hg直到特定版本,而docker自己創建一個接近完全相同的副本。

如果你想在Docker和SCM之間進行漂亮的集成,GitLab會提供它自己的內置Docker註冊表。這使得在構建管道中發布Docker鏡像變得輕而易舉。

GitLab Docker註冊表的另一個巨大優勢是它支持每個GitLab倉庫的多個Docker倉庫。這允許您為每個分支,每個提交,每個環境或任何您需要的任何內容創建一個新的Docker回購。

My company leverages this by pushing our images to repos based on the branch, tagged with their commit. Here is an example: project-name/branch-name:commit-SHA

Or if you have multiple Docker images being build for a particular branch (like a front-end Angular app and it's back-end API that it talks to), you can scope it even further, like so:
project-name/branch-name/api:commit-SHA
project-name/branch-name/front-end:commit-SHA

對於可用於範圍設定的斜杠(/)的數量沒有限制。這使得在部署圖像時能夠很容易地確定圖像的確切提交。出於這個原因,我的公司幾乎從不使用通用的'最新'標簽。我們更喜歡哪個圖像部署在哪裏的特殊性。

您仍然可以將相同的“多個docker repo”邏輯應用於任何Docker註冊表。您必須查找特定系統的動態創建新回購的功能,以及與CI/CD管道集成的容易程度。