official images
1.0.0
Docker 官方映像像是託管在 Docker Hub 上的精選映像。主要原則是：
專注於免費和開源軟體
支援多種架構
舉例說明Dockerfile最佳實踐
積極重建更新和安全修復
遵守上游建議
在適當的情況下為容器環境添加最低限度的生活品質行為
請參閱 Docker 的文檔以取得該程式的高級概述。
本質上，我們努力聽取上游關於他們打算如何使用其軟體的建議。許多影像如果不是由相關上游專案直接維護的話，也是與相關上游專案合作維護的。此外，我們的目標是舉例說明 Dockerfile 的最佳實踐，以便在您製作或衍生自己的映像時作為參考。
（如果您是存在鏡像的上游代表並且您想參與其中，請參閱下面的維護部分！）
一些鏡像已移植到其他架構，其中許多鏡像得到了官方支援（不同程度）。
arm32v6 ）：https://hub.docker.com/u/arm32v6/arm32v7 ）：https://hub.docker.com/u/arm32v7/arm64v8 ）：https://hub.docker.com/u/arm64v8/amd64 ）：https://hub.docker.com/u/amd64/windows-amd64 ): https://hub.docker.com/u/winamd64/arm32v5 ）：https://hub.docker.com/u/arm32v5/ppc64le ）：https://hub.docker.com/u/ppc64le/s390x )：https://hub.docker.com/u/s390x/mips64le ）：https://hub.docker.com/u/mips64le/riscv64 ）：https://hub.docker.com/u/riscv64/i386 ）：https://hub.docker.com/u/i386/截至 2017 年 9 月 12 日，這些其他架構透過「清單清單」（在 OCI 映像規格中也稱為「索引」）包含在無前綴映像下，例如docker run hello-world應該在所有支援的平台上按原樣運行。
如果您對它們是如何構建的感到好奇，請訪問 https://doi-janky.infosiftr.net/job/multiarch/ 查看構建腳手架。
請參閱下面的多架構部分，以了解為官方映像添加更多架構的建議。
是的！我們有一個專門的常見問題解答儲存庫，我們嘗試在其中收集其他常見問題（關於該計劃和我們的實踐）。
感謝您對 Docker 官方鏡像專案的興趣！我們努力使這些說明盡可能簡單明了，但如果您發現自己迷失了，請隨時在#docker-library頻道中的 Libera.Chat IRC 上尋找我們，或者在此處創建 GitHub 問題。
請務必熟悉 Docker Hub 上的官方儲存庫以及 Docker 文件中編寫 Dockerfile 的最佳實踐。這些將成為官方影像維護人員執行審查過程的基礎。如果您希望審核過程更加順利，請在提交拉取請求之前確保您的Dockerfile遵守此處以及下文中提到的所有要點。
此外，這些映像的 Hub 描述目前單獨儲存在docker-library/docs儲存庫中，其README.md檔案詳細說明了其結構以及如何對其做出貢獻。請準備好在那裡提交 PR，等待您的圖片在這裡被接受。
由於官方映像旨在成為 Docker 新手的學習工具，以及高級用戶建立生產版本的基礎映像，因此我們會審查每個提議的Dockerfile ，以確保其滿足品質和可維護性的最低標準。雖然其中一些標準很難定義（由於主觀性），但這裡盡可能多地定義，同時在適當的情況下遵循「最佳實踐」。
維護者在審查期間可以使用的清單可以在NEW-IMAGE-CHECKLIST.md中找到。
應及時關注版本更新和安全性修復。
如果您不代表上游，而上游對維護映像感興趣，則應採取措施確保映像維護權順利過渡到上游。
對於有興趣接管現有儲存庫維護權的上游，第一步是參與現有儲存庫。對問題發表評論、提出更改以及在“圖像社區”中讓自己出名（即使該“社區”只是當前的維護者）都是重要的起點，以確保現有貢獻者和用戶不會對過渡感到意外。
接手現有儲存庫時，請確保原始儲存庫的整個 Git 歷史記錄都保存在新的上游維護的儲存庫中，以確保審核過程在過渡期間不會停止。這最容易透過從現有儲存庫中分叉新的來完成，但也可以透過直接從原始儲存庫中取得提交並將其推送到新儲存庫中來完成（即git fetch https://github.com/jsmith/example.git master 、 git rebase FETCH_HEAD 、 git push -f ）。在 GitHub 上，另一種方法是轉移 git 儲存庫的所有權。這可以在不授予任一組管理員存取其他擁有者儲存庫的情況下完成：
重建相同的Dockerfile應該會導致打包相同版本的映像，即使第二個建置發生在幾個版本之後，或者建置應該徹底失敗，這樣標記為0.1.0的Dockerfile的無意重建就不會結束包含0.2.3 。例如，如果使用apt安裝映像的主程序，請確保將其固定到特定版本（例如： ... apt-get install -y my-package=0.1.0 ... ）。對於apt安裝的依賴套件，通常不需要將它們固定到某個版本。
任何官方鏡像都不能源自或依賴非官方鏡像（允許非鏡像scratch和在.external-pins中固定的有意限制的例外情況——另請參閱.external-pins/list.sh ）。
所有官方鏡像都應提供一致的介面。初級使用者應該能夠docker run official-image bash （或sh ），而無需了解--entrypoint 。對於進階使用者來說，利用入口點也很好，這樣他們就可以docker run official-image --arg1 --arg2而無需指定要執行的二進位。
如果啟動過程不需要參數，只需使用CMD ：
CMD [ "irb" ]如果需要在啟動時完成初始化（例如建立初始資料庫），請結合使用ENTRYPOINT和CMD ：
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ]確保docker run official-image bash （或sh ）也能正常運作。最簡單的方法是檢查預期的命令，如果是其他命令，只需exec "$@" （運行傳遞的任何內容，正確保持參數轉義）。
#! /bin/sh
set -e
# this if will check if the first argument is a flag
# but only works if all arguments require a hyphenated flag
# -v; -SL; -f arg; etc will work, but not arg1 arg2
if [ " $# " -eq 0 ] || [ " ${1 # -} " != " $1 " ] ; then
set -- mongod " $@ "
fi
# check for the expected command
if [ " $1 " = ' mongod ' ] ; then
# init db stuff....
# use gosu (or su-exec) to drop to a non-root user
exec gosu mongod " $@ "
fi
# else default to run whatever the user wanted like "bash" or "sh"
exec " $@ "如果映像僅包含主可執行檔及其連結庫（即沒有 shell），那麼可以使用可執行檔作為ENTRYPOINT ，因為這是唯一可以運行的東西：
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ]判斷這是否合適的最常見指標是映像Dockerfile scratch開始（ FROM scratch ）。
嘗試使Dockerfile易於理解/閱讀。為了簡潔起見，將複雜的初始化細節放入獨立腳本中並僅在Dockerfile中添加RUN命令可能很誘人。然而，這會導致產生的Dockerfile過於不透明，這樣的Dockerfile不太可能通過審核。相反，建議將所有初始化命令作為適當的RUN或ENV命令組合放入Dockerfile中。要找到好的例子，請查看目前的官方圖片。
在撰寫本文時的一些範例：
遵循 Docker 指南，強烈建議每個容器產生的映像僅包含一個關注點；這主要意味著每個容器只有一個進程，因此不需要完整的初始化系統。在兩種情況下，類似 init 的進程會對容器有所幫助。第一個是訊號處理。如果啟動的程序沒有透過退出來處理SIGTERM ，則它不會被殺死，因為它在容器中的 PID 為 1（請參閱 docker 文件中前台部分末尾的「注意」）。第二種情況就是殭屍收割。如果進程產生子進程並且沒有正確取得它們，則會導致進程表已滿，這可能會阻止整個系統產生任何新進程。對於這兩個問題，我們推薦 tini。它非常小，具有最小的外部依賴性，填補了這些角色中的每一個，並且只執行收割和訊號轉發的必要部分。
請務必根據需要在CMD或ENTRYPOINT中使用 tini。
最好從發行版提供的軟體包（例如apt-get install tini ）安裝 tini 。如果 tini 在您的發行版中不可用或太舊，以下是要新增到 tini 中的Dockerfile片段：
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
ENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7
RUN set -eux;
wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" ;
wget -O /usr/local/bin/tini.asc "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc" ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$TINI_SIGN_KEY" ;
gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini;
command -v gpgconf && gpgconf --kill all || :;
rm -r "$GNUPGHOME" /usr/local/bin/tini.asc;
chmod +x /usr/local/bin/tini;
tini --version在這一點上，經驗最終勝過文檔，成為啟蒙之路，但以下提示可能會有所幫助：
盡可能避免COPY / ADD ，但在必要時，盡可能具體（即COPY one-file.sh /somewhere/而不是COPY . /somewhere ）。
原因是COPY指令的快取將檔案mtime變更視為快取失效，這有時會使COPY的快取行為變得不可預測，特別是當.git是需要COPY的一部分時（例如）。
確保不太可能發生變化的行出現在更有可能發生變化的行之前（需要注意的是，每行都應該產生一個在不假設後面的行的情況下仍能成功運行的圖像）。
例如，包含軟體版本號 ( ENV MYSOFTWARE_VERSION 4.2 ) 的行應位於設定 APT 儲存庫.list檔案的行 ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ）。
Dockerfile編寫應有助於減輕建置期間的攔截攻擊。我們的要求集中在三個主要目標：驗證來源、驗證作者和驗證內容；這些分別透過以下方式完成： 盡可能使用 https；在Dockerfile中匯入具有完整指紋的 PGP 金鑰以檢查簽章；將校驗和直接嵌入到Dockerfile中。應盡可能使用這三種方法。當沒有發布簽名時，只能使用 https 和嵌入的校驗和。作為最後的手段，如果網站沒有可用的 https 且沒有簽名，則只接受嵌入的校驗和。
建議使用 https 來下載所需工件的目的是確保下載來自受信任的來源，而這也恰好使攔截變得更加困難。
推薦 PGP 簽章驗證的目的是確保只有授權使用者才能發布給定的工件。匯入 PGP 金鑰時，請盡可能使用keys.openpgp.org服務（否則最好使用keyserver.ubuntu.com ）。另請參閱有關金鑰和驗證的常見問題解答部分。
建議進行校驗和驗證的目的是驗證工件是否符合預期。這確保了當遠端內容變更時，Dockerfile 也會變更並提供自然的docker build快取清理。作為一個額外的好處，這還可以防止在版本不佳的檔案上意外下載比預期更新的工件。
以下是一些範例：
首選：透過 https 下載，PGP 金鑰完整指紋導入和asc驗證，嵌入式校驗和驗證。
ENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)
RUN set -eux;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc;
export GNUPGHOME= "$(mktemp -d)" ;
# gpg: key F73C700D: public key "Larry Hastings <[email protected]>" imported
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D;
gpg --batch --verify python.tar.xz.asc python.tar.xz;
rm -r "$GNUPGHOME" python.tar.xz.asc;
echo "$PYTHON_DOWNLOAD_SHA512 *python.tar.xz" | sha512sum --strict --check;
# install備用：將完整金鑰指紋匯入到 apt 中，它將在下載和安裝軟體包時檢查簽名和校驗和。
RUN set -eux;
key= 'A4A9406876FCBD3C456770C88C718D3B5072E1F5' ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ;
gpg --batch --armor --export "$key" > /etc/apt/trusted.gpg.d/mysql.gpg.asc;
gpgconf --kill all;
rm -rf "$GNUPGHOME" ;
apt-key list > /dev/null
RUN set -eux;
echo "deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}" > /etc/apt/sources.list.d/mysql.list;
apt-get update;
apt-get install -y mysql-community-client= "${MYSQL_VERSION}" mysql-community-server-core= "${MYSQL_VERSION}" ;
rm -rf /var/lib/apt/lists/*;
# ... （順便說一句， rm -rf /var/lib/apt/lists/*與apt-get update大致相反——它確保該層不包含額外的約 8MB 的 APT 包列表數據，並且強制執行適當的apt-get update使用。
安全性較低的替代方案：將校驗和嵌入到Dockerfile中。
ENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)
RUN set -eux;
curl -fL -o ruby.tar.gz "https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz" ;
echo "$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz" | sha256sum --strict --check;
# install注意：使用 SHA1 或 MD5 應被視為“最後手段的校驗和”，因為兩者通常被認為是不安全的：
不可接受：透過 http(s) 下載檔案而不進行驗證。
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install 預設情況下，Docker 容器以較低的權限執行：白名單 Linux 功能、控制群組和預設 Seccomp 設定檔（1.10+ 帶主機支援）。在容器中運行的軟體可能需要額外的權限才能正常運行，並且有許多命令列選項可以自訂容器執行。請參閱docker run Reference 和 Seccomp for Docker 以供參考。
需要額外權限的官方儲存庫應指定軟體運行的最小命令列選項集，如果這引入了重大的可移植性或安全性問題，則仍可能被拒絕。一般來說，不允許使用--privileged ，但--cap-add和--device選項的組合可能是可以接受的。此外， --volume可能會很棘手，因為有許多主機檔案系統位置會引入可移植性/安全性問題（例如 X11 套接字）。
對於構成安全修復的映像更新，我們建議採取一些措施來幫助確保盡快合併、建置和發布您的更新：
[email protected]發送電子郵件，以便我們提前了解並估算時間（以便我們可以適當安排傳入更新的時間）。[security] （例如， [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ）。每個儲存庫可以為任何和所有標籤指定多個架構。如果未指定體系結構，則映像將在amd64 （又稱 x86-64）上的 Linux 中建置。若要指定更多或不同的體系結構，請使用Architectures欄位（逗號分隔列表，刪除空格）。有效的架構可以在 Bashbrew 的oci-platform.go檔案中找到：
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64任何給定標籤的Architectures必須是其FROM標籤的Architectures的嚴格子集。
映像庫檔案中的每個條目必須有一個可用於多種架構的Dockerfile 。這意味著每個受支援的體系結構將具有相同的FROM行（例如FROM debian:bookworm ）。請參閱golang 、 docker 、 haproxy和php以取得每個條目使用一個Dockerfile的程式庫檔案範例，並查看它們各自的 git 儲存庫以取得範例Dockerfile 。
如果 Dockerfile 的不同部分只發生在一種架構或另一種架構中，請使用控制流程（例如if / case ）以及dpkg --print-architecture或apk -print-arch來偵測使用者空間架構。僅在無法安裝更準確的工具時才使用uname進行體系結構檢測。請參閱 golang 的範例，其中某些架構需要從上游來源套件建立二進位文件，而某些架構只需下載二進位版本。
對於像debian這樣的基礎映像，需要有一個不同的Dockerfile和建置上下文，以便ADD特定於架構的二進位文件，這是上述情況的一個有效例外。由於這些影像使用相同的Tags ，因此它們需要位於同一條目中。使用GitRepo 、 GitFetch 、 GitCommit和Directory的體系結構特定字段，這些字段是用連字符 ( - ) 和字段連接的體系結構（例如arm32v7-GitCommit ）。任何沒有特定於體系結構欄位的體系結構都會使用預設欄位（例如，沒有arm32v7-Directory意味著Directory將用於arm32v7 ）。有關範例，請參閱庫中的debian或ubuntu檔案。以下是hello-world的範例：
Maintainers: Tianon Gravi <[email protected]> (@tianon),
Joseph Ferguson <[email protected]> (@yosifkit)
GitRepo: https://github.com/docker-library/hello-world.git
GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Tags: latest
Architectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x
# all the same commit; easy for us to generate this way since they could be different
amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
amd64-Directory: amd64/hello-world
arm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v5-Directory: arm32v5/hello-world
arm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v7-Directory: arm32v7/hello-world
arm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm64v8-Directory: arm64v8/hello-world
ppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
ppc64le-Directory: ppc64le/hello-world
s390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
s390x-Directory: s390x/hello-world
Tags: nanoserver
Architectures: windows-amd64
# if there is only one architecture, you can use the unprefixed fields
Directory: amd64/hello-world/nanoserver
# or use the prefixed versions
windows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Constraints: nanoserver
有關庫文件格式的更多信息，請參閱指令格式部分。
提出新的官方形像不應輕易進行。我們期望並要求您承諾維護您的形象（包括特別是適時的及時更新，如上所述）。
庫定義檔是在official-images儲存庫的library/目錄中找到的純文字檔案。每個庫檔案控制 Docker Hub 描述中顯示的目前「受支援」的映像標籤集。從庫檔案中刪除的標籤不會從 Docker Hub 中刪除，因此舊版本可以繼續使用，但不會由上游或官方映像的維護者維護。庫檔案中的標籤僅透過更新該庫檔案或更新其基礎鏡像來建置（即，在建置FROM debian:bookworm debian:bookworm的鏡像）。當庫有更新時，只有庫檔案中的內容才會被重建。
鑑於此政策，有必要澄清一些情況：回填版本、候選版本和持續整合建置。當提出新的儲存庫時，通常會在初始拉取請求中包含一些不受支援的舊版本，並同意在接受後立即刪除它們。不要與綜合歷史檔案混淆，這不是本意。術語「支援」有點延伸的另一個常見情況是候選版本。候選版本實際上只是預期壽命較短的版本的命名約定，因此它們是完全可以接受和鼓勵的。與發布候選版本不同，持續整合建置具有基於程式碼提交或定期規劃的完全自動化的發布週期，這是不合適的。
強烈建議您在創建新的library/文件內容（以及歷史記錄，以了解它們如何隨著時間的推移而變化），以熟悉流行的約定並進一步幫助簡化審核過程（因此我們可以專注於內容而不是深奧的格式或標籤使用/命名）。
定義檔案的檔案名稱將決定它在 Docker Hub 上建立的映像儲存庫的名稱。例如， library/ubuntu檔案將在ubuntu儲存庫中建立標籤。
儲存庫的標籤應反映上游的版本或變體。例如，Ubuntu 14.04 也稱為 Ubuntu Trusty Tahr，但通常簡稱為 Ubuntu Trusty（尤其是在使用中），因此ubuntu:14.04 （版本號）和ubuntu:trusty （版本名稱）是相同映像內容的適當別名。在 Docker 中， latest標籤是一個特例，但它有點用詞不當； latest確實是「預設」標籤。執行docker run xyz時，Docker 會將其解釋為docker run xyz:latest 。考慮到這一背景，沒有其他標籤包含字串latest ，因為它不是用戶期望或鼓勵實際鍵入的內容（即， xyz:latest實際上應該簡單地用作xyz ）。換句話說，「XYZ 的最高 2.2 系列版本」的別名應該是xyz:2.2 ，而不是xyz:2.2-latest 。同樣，如果xyz:latest存在 Alpine 變體，則應將其別名為xyz:alpine ，而不是xyz:alpine-latest或xyz:latest-alpine 。
強烈建議為版本號標籤指定別名，以便用戶輕鬆保留特定係列的「最新」版本。例如，鑑於目前支援的 XYZ 軟體版本為 2.3.7 和 2.2.4，建議的別名將分別為Tags: 2.3.7, 2.3, 2, latest和Tags: 2.2.4, 2.2 。在此範例中，使用者可以使用xyz:2.2輕鬆使用 2.2 系列的最新修補程式版本，如果需要較小的粒度，則可以使用xyz:2 （Python 是一個很好的範例，說明了它最明顯有用的地方- python:2和python:3非常不同，可以被認為是 Python 每個主要版本軌道的latest標籤）。
如上所述， latest實際上是「預設」的，因此，如果使用者不知道或不關心他們使用哪個版本，則它作為別名的映像應該反映使用者應該使用哪個版本或軟體變體。以 Ubuntu 為例， ubuntu:latest指向最新的 LTS 版本，因為如果大多數用戶知道自己想要 Ubuntu 但不知道或不關心哪個版本（特別是考慮到它將是在任何給定時間最「穩定」且得到良好支援的版本）。
清單檔案格式正式基於 RFC 2822，因此對於已經熟悉許多流行互聯網協定/格式（例如 HTTP 或電子郵件）「標頭」的人來說應該很熟悉。
主要添加內容的靈感來自 Debian 通常使用 2822 的方式——即，以#開頭的行被忽略，“條目”由空行分隔。
第一個條目是影像的「全域」元資料。全域條目中唯一必填的欄位是Maintainers ，其值以逗號分隔，格式為Name <email> (@github)或Name (@github) 。全域條目中指定的任何字段都將成為其餘條目的預設字段，並且可以在單一條目中覆蓋。
# this is a comment and will be ignored
Maintainers: John Smith <[email protected]> (@example-jsmith),
Anne Smith <[email protected]> (@example-asmith)
GitRepo: https://github.com/example/docker-example.git
GitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# this is also a comment, and will also be ignored
Tags: 1.2.3, 1.2, 1, latest
Directory: 1
Tags: 2.0-rc1, 2.0-rc, 2-rc, rc
GitRepo: https://github.com/example/docker-example-rc.git
GitFetch: refs/heads/2.0-pre-release
GitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead
Directory: 2
File: Dockerfile-to-use
Bashbrew 會在指定的提交 ( GitCommit ) 處從 Git 儲存庫 ( GitRepo ) 中取得程式碼。如果透過取得關聯的GitRepo的master無法取得所引用的提交，則有必要為GitFetch提供一個值，以便告訴 Bashbrew 要取得哪些引用以獲得必要的提交。
建構的鏡像將被標記為<manifest-filename>:<tag> （即Tags值為1.6, 1, latest library/golang將建立golang:1.6 、 golang:1和golang:latest標籤）。
或者，如果Directory存在，Bashbrew 將在指定的子目錄中而不是在根目錄中尋找Dockerfile （並且Directory將用作建置的「上下文」而不是儲存庫的頂層）。如果存在File ，則將使用指定的檔案名稱而不是Dockerfile 。
有關如何為特定架構指定不同的GitRepo 、 GitFetch 、 GitCommit或Directory的詳細信息，請參閱多架構部分。
library/資料夾中建立一個新文件。它的名稱將是您在 Hub 上的儲存庫的名稱。Bashbrew ( bashbrew ) 是一個用於克隆、建構、標記和推送 Docker 官方映像的工具。有關更多信息，請參閱 Bashbrew README 。
