official images
1.0.0
Gambar Resmi Docker adalah gambar hasil kurasi yang dihosting di Docker Hub. Prinsip utamanya adalah:
Fokus pada Perangkat Lunak Bebas dan Sumber Terbuka
Mendukung banyak arsitektur
Contohkan praktik terbaik Dockerfile
Secara aktif membangun kembali untuk pembaruan dan perbaikan keamanan
Patuhi rekomendasi hulu
Tambahkan perilaku kualitas hidup minimal untuk lingkungan kontainer jika sesuai
Lihat dokumentasi Docker untuk ikhtisar program tingkat tinggi yang bagus.
Intinya kami berusaha untuk memperhatikan rekomendasi upstream tentang bagaimana mereka ingin perangkat lunak mereka digunakan. Banyak gambar yang dikelola melalui kolaborasi dengan proyek hulu yang relevan jika tidak dikelola langsung oleh mereka. Selain itu, kami bertujuan untuk memberikan contoh praktik terbaik Dockerfiles untuk dijadikan referensi saat membuat atau mengambil gambar Anda sendiri darinya.
(Jika Anda adalah perwakilan dari upstream yang memiliki gambar dan ingin terlibat, silakan lihat bagian Pemeliharaan di bawah!)
Beberapa gambar telah di-porting untuk arsitektur lain, dan banyak di antaranya yang didukung secara resmi (pada tingkat yang berbeda-beda).
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/ Mulai 12-09-2017, arsitektur lain ini disertakan dalam gambar non-awalan melalui "daftar manifes" (juga dikenal sebagai "indeks" dalam spesifikasi gambar OCI), sehingga, misalnya, docker run hello-world seharusnya dijalankan apa adanya di semua platform yang didukung.
Jika Anda penasaran tentang cara pembuatannya, kunjungi https://doi-janky.infosiftr.net/job/multiarch/ untuk melihat perancah pembuatannya.
Lihat bagian multi-lengkungan di bawah untuk rekomendasi dalam menambahkan lebih banyak arsitektur ke gambar resmi.
Ya! Kami memiliki gudang FAQ khusus tempat kami mencoba mengumpulkan pertanyaan umum lainnya (baik tentang program maupun praktik kami).
Terima kasih atas minat Anda pada proyek gambar resmi Docker! Kami berusaha untuk membuat instruksi ini sesederhana dan semudah mungkin, tetapi jika Anda bingung, jangan ragu untuk mencari kami di Libera.Chat IRC di saluran #docker-library atau dengan membuat masalah GitHub di sini.
Pastikan Anda memahami Repositori Resmi di Docker Hub dan Praktik terbaik untuk menulis File Docker di dokumentasi Docker. Ini akan menjadi dasar proses peninjauan yang dilakukan oleh pengelola gambar resmi. Jika Anda ingin proses peninjauan berjalan lebih lancar, pastikan Dockerfile Anda mematuhi semua poin yang disebutkan di sana, serta di bawah, sebelum mengirimkan permintaan penarikan.
Selain itu, deskripsi Hub untuk gambar-gambar ini saat ini disimpan secara terpisah di repositori docker-library/docs , yang file README.md nya menjelaskan lebih lanjut tentang strukturnya dan cara berkontribusi ke dalamnya. Harap bersiap untuk mengirimkan PR di sana juga, menunggu penerimaan gambar Anda di sini.
Karena gambar resmi dimaksudkan sebagai alat pembelajaran bagi mereka yang baru mengenal Docker serta gambar dasar bagi pengguna tingkat lanjut untuk membangun rilis produksi mereka, kami meninjau setiap Dockerfile yang diusulkan untuk memastikan bahwa gambar tersebut memenuhi standar minimum untuk kualitas dan pemeliharaan. Meskipun beberapa standar tersebut sulit untuk didefinisikan (karena subjektivitas), sebisa mungkin standar tersebut didefinisikan di sini, sambil juga mengikuti "Praktik Terbaik" jika diperlukan.
Daftar periksa yang dapat digunakan oleh pengelola selama peninjauan dapat ditemukan di NEW-IMAGE-CHECKLIST.md .
Perubahan versi dan perbaikan keamanan harus ditangani tepat waktu.
Jika Anda tidak mewakili upstream dan upstream tertarik untuk mempertahankan citra, langkah-langkah harus diambil untuk memastikan kelancaran transisi pemeliharaan citra ke upstream.
Bagi upstream yang tertarik untuk mengambil alih pengelolaan repositori yang sudah ada, langkah pertama adalah terlibat dalam repositori yang sudah ada. Memberikan komentar mengenai isu-isu, mengusulkan perubahan, dan membuat diri Anda dikenal dalam "komunitas gambar" (walaupun "komunitas" tersebut hanyalah pengelola saat ini) adalah titik awal yang penting untuk memastikan bahwa transisi tersebut tidak mengejutkan bagi kontributor dan pengguna yang ada.
Saat mengambil alih repositori yang ada, harap pastikan bahwa seluruh riwayat Git dari repositori asli disimpan di repositori baru yang dikelola upstream untuk memastikan proses peninjauan tidak terhenti selama transisi. Hal ini paling mudah dilakukan dengan melakukan fork yang baru dari repositori yang sudah ada, namun juga dapat dilakukan dengan mengambil komit langsung dari yang asli dan memasukkannya ke dalam repo baru (yaitu, git fetch https://github.com/jsmith/example.git master , git rebase FETCH_HEAD , git push -f ). Di GitHub, alternatifnya adalah memindahkan kepemilikan repositori git. Hal ini dapat dilakukan tanpa memberikan akses kepada admin grup ke repositori pemilik lainnya:
Membangun kembali Dockerfile yang sama akan menghasilkan versi gambar yang sama yang dikemas, bahkan jika build kedua terjadi beberapa versi lebih baru, atau build harus langsung gagal, sehingga pembangunan kembali Dockerfile yang diberi tag 0.1.0 secara tidak sengaja tidak berakhir up berisi 0.2.3 . Misalnya, jika menggunakan apt untuk menginstal program utama untuk gambar tersebut, pastikan untuk menyematkannya ke versi tertentu (misal: ... apt-get install -y my-package=0.1.0 ... ). Untuk paket dependen yang diinstal oleh apt biasanya tidak perlu menyematkannya ke suatu versi.
Tidak ada gambar resmi yang dapat diturunkan dari, atau bergantung pada, gambar non-resmi (mengizinkan scratch non-gambar dan pengecualian terbatas yang sengaja disematkan di .external-pins -- lihat juga .external-pins/list.sh ).
Semua gambar resmi harus menyediakan antarmuka yang konsisten. Pengguna pemula harus dapat docker run official-image bash (atau sh ) tanpa perlu mempelajari tentang --entrypoint . Ini juga bagus bagi pengguna tingkat lanjut untuk memanfaatkan titik masuk, sehingga mereka dapat docker run official-image --arg1 --arg2 tanpa harus menentukan biner yang akan dieksekusi.
Jika proses startup tidak memerlukan argumen, gunakan saja CMD :
CMD [ "irb" ] Jika ada inisialisasi yang perlu dilakukan di awal, seperti membuat database awal, gunakan ENTRYPOINT bersama dengan CMD :
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] Pastikan docker run official-image bash (atau sh ) juga berfungsi. Cara termudah adalah dengan memeriksa perintah yang diharapkan dan jika itu adalah sesuatu yang lain, exec "$@" (jalankan apa pun yang diteruskan, jaga agar argumen tetap lolos).
#! /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 " $@ " Jika gambar hanya berisi executable utama dan perpustakaan tertautnya (yaitu tanpa shell) maka boleh saja menggunakan executable sebagai ENTRYPOINT , karena hanya itulah yang dapat dijalankan:
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ] Indikator paling umum apakah ini tepat adalah bahwa gambar Dockerfile dimulai dengan scratch ( FROM scratch ).
Cobalah untuk membuat Dockerfile mudah dipahami/dibaca. Mungkin tergoda, demi singkatnya, untuk memasukkan detail inisialisasi yang rumit ke dalam skrip mandiri dan hanya menambahkan perintah RUN di Dockerfile . Namun, hal ini menyebabkan Dockerfile yang dihasilkan menjadi terlalu buram, dan Dockerfile tersebut kemungkinan besar tidak lolos peninjauan. Sebagai gantinya, disarankan untuk memasukkan semua perintah untuk inisialisasi ke dalam Dockerfile sebagai kombinasi perintah RUN atau ENV yang sesuai. Untuk menemukan contoh yang bagus, lihat gambar resmi terkini.
Beberapa contoh pada saat penulisan:
Mengikuti pedoman Docker, sangat disarankan agar gambar yang dihasilkan hanya satu perhatian per kontainer; pada dasarnya ini berarti hanya satu proses per container, sehingga tidak diperlukan sistem init yang lengkap. Ada dua situasi di mana proses seperti init akan berguna untuk container. Yang pertama adalah penanganan sinyal. Jika proses yang diluncurkan tidak menangani SIGTERM dengan keluar, proses tersebut tidak akan dimatikan karena merupakan PID 1 di dalam container (lihat "CATATAN" di akhir bagian Foreground di dokumen buruh pelabuhan). Situasi kedua adalah penuaian zombie. Jika suatu proses memunculkan proses anak dan tidak menuainya dengan benar, hal ini akan menyebabkan tabel proses penuh, yang dapat mencegah seluruh sistem memunculkan proses baru. Untuk kedua masalah ini kami merekomendasikan tini. Ini sangat kecil, memiliki ketergantungan eksternal yang minimal, memenuhi setiap peran ini, dan hanya melakukan bagian-bagian penting dalam pengumpulan dan penerusan sinyal.
Pastikan untuk menggunakan tini di CMD atau ENTRYPOINT yang sesuai.
Yang terbaik adalah menginstal tini dari paket yang disediakan distribusi (mis. apt-get install tini ). Jika tini tidak tersedia di distribusi Anda atau terlalu lama, berikut cuplikan Dockerfile untuk ditambahkan ke tini:
# 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 --versionDi sinilah pengalaman akhirnya mengalahkan dokumentasi jalan menuju pencerahan, namun tips berikut mungkin bisa membantu:
Hindari COPY / ADD bila memungkinkan, tetapi bila perlu, buatlah sespesifik mungkin (yaitu, COPY one-file.sh /somewhere/ dari pada COPY . /somewhere ).
Alasannya adalah bahwa instruksi cache untuk COPY menganggap perubahan mtime file sebagai cache bust, yang terkadang dapat membuat perilaku cache COPY tidak dapat diprediksi, terutama ketika .git adalah bagian dari apa yang perlu di COPY (misalnya).
Pastikan bahwa garis yang kecil kemungkinannya untuk berubah muncul sebelum garis yang kemungkinan besar berubah (dengan peringatan bahwa setiap garis harus menghasilkan gambar yang masih berjalan dengan sukses tanpa asumsi garis berikutnya).
Misalnya, baris yang berisi nomor versi perangkat lunak ( ENV MYSOFTWARE_VERSION 4.2 ) harus muncul setelah baris yang menyiapkan file .list repositori APT ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ).
Dockerfile harus ditulis untuk membantu mengurangi serangan intersepsi selama pembuatan. Persyaratan kami berfokus pada tiga tujuan utama: memverifikasi sumber, memverifikasi penulis, dan memverifikasi konten; hal ini masing-masing dapat dilakukan dengan cara berikut: menggunakan https jika memungkinkan; mengimpor kunci PGP dengan sidik jari lengkap di Dockerfile untuk memeriksa tanda tangan; menyematkan checksum langsung di Dockerfile . Ketiganya harus digunakan bila memungkinkan. Hanya https dan checksum tertanam yang dapat digunakan ketika tidak ada tanda tangan yang dipublikasikan. Sebagai upaya terakhir, hanya checksum tertanam yang dapat diterima jika situs tidak memiliki https dan tidak ada tanda tangan.
Tujuan merekomendasikan penggunaan https untuk mengunduh artefak yang diperlukan adalah untuk memastikan bahwa unduhan tersebut berasal dari sumber tepercaya yang juga membuat intersepsi menjadi jauh lebih sulit.
Tujuan merekomendasikan verifikasi tanda tangan PGP adalah untuk memastikan bahwa hanya pengguna yang berwenang yang menerbitkan artefak tertentu. Saat mengimpor kunci PGP, harap gunakan layanan keys.openpgp.org bila memungkinkan (lebih memilih keyserver.ubuntu.com ). Lihat juga bagian FAQ tentang kunci dan verifikasi.
Tujuan merekomendasikan verifikasi checksum adalah untuk memverifikasi bahwa artefak tersebut sesuai dengan yang diharapkan. Hal ini memastikan bahwa ketika konten jarak jauh berubah, Dockerfile juga akan berubah dan menyediakan cache docker build alami. Sebagai bonus, ini juga mencegah pengunduhan artefak yang lebih baru dari perkiraan secara tidak sengaja pada file dengan versi yang buruk.
Di bawah ini beberapa contohnya:
Pilihan : unduh melalui https, impor sidik jari penuh kunci PGP dan verifikasi asc , checksum tertanam diverifikasi.
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;
# installAlternatif : sidik jari kunci lengkap diimpor ke apt yang akan memeriksa tanda tangan dan checksum ketika paket diunduh dan diinstal.
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/*;
# ... (Sebagai catatan tambahan, rm -rf /var/lib/apt/lists/* secara kasar merupakan kebalikan dari apt-get update -- ini memastikan bahwa lapisan tersebut tidak menyertakan tambahan ~8MB data daftar paket APT, dan menerapkan penggunaan apt-get update yang sesuai.)
Alternatif Kurang Aman : sematkan checksum ke dalam 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;
# installCatatan: penggunaan SHA1 atau MD5 harus dianggap sebagai "checksum pilihan terakhir" karena keduanya umumnya dianggap tidak aman:
Tidak dapat diterima : unduh file melalui http(s) tanpa verifikasi.
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install Secara default, container Docker dijalankan dengan hak istimewa yang dikurangi: kemampuan Linux yang masuk daftar putih, Grup Kontrol, dan profil Seccomp default (1.10+ dengan dukungan host). Perangkat lunak yang berjalan dalam sebuah container mungkin memerlukan hak tambahan agar dapat berfungsi dengan benar, dan ada sejumlah opsi baris perintah untuk menyesuaikan eksekusi container. Lihat Referensi docker run dan Seccomp untuk Docker untuk referensi.
Repositori Resmi yang memerlukan hak istimewa tambahan harus menentukan serangkaian opsi baris perintah minimal agar perangkat lunak dapat berfungsi, dan mungkin masih ditolak jika hal ini menimbulkan masalah portabilitas atau keamanan yang signifikan. Secara umum, --privileged tidak diperbolehkan, namun kombinasi opsi --cap-add dan --device mungkin dapat diterima. Selain itu, --volume bisa jadi rumit karena ada banyak lokasi sistem file host yang menimbulkan masalah portabilitas/keamanan (misalnya soket X11).
Untuk pembaruan gambar yang merupakan perbaikan keamanan, ada beberapa hal yang kami sarankan untuk membantu memastikan pembaruan Anda digabungkan, dibuat, dan dirilis secepat mungkin:
[email protected] beberapa hari (bisnis) sebelumnya untuk memberi kami informasi awal dan perkiraan waktu (sehingga kami dapat menjadwalkan waktu untuk pembaruan yang masuk dengan tepat).[security] dalam judul permintaan penarikan Anda (misalnya, [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ). Setiap repo dapat menentukan beberapa arsitektur untuk setiap dan semua tag. Jika tidak ada arsitektur yang ditentukan, image dibuat di Linux pada amd64 (alias x86-64). Untuk menentukan arsitektur yang lebih banyak atau berbeda, gunakan bidang Architectures (daftar yang dibatasi koma, spasi dipangkas). Arsitektur yang valid ditemukan di file oci-platform.go Bashbrew:
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64 Architectures dari setiap tag tertentu harus merupakan subset ketat dari Architectures dari tag tersebut FROM .
Gambar harus memiliki satu Dockerfile per entri di file perpustakaan yang dapat digunakan untuk beberapa arsitektur. Artinya setiap arsitektur yang didukung akan memiliki baris FROM yang sama (misalnya FROM debian:bookworm ). Lihat golang , docker , haproxy , dan php untuk contoh file perpustakaan menggunakan satu Dockerfile per entri dan lihat repo git masing-masing misalnya Dockerfile s.
Jika bagian berbeda dari Dockerfile hanya terjadi di satu arsitektur atau lainnya, gunakan aliran kontrol (misalnya if / case ) bersama dengan dpkg --print-architecture atau apk -print-arch untuk mendeteksi arsitektur ruang pengguna. Hanya gunakan uname untuk deteksi arsitektur ketika alat yang lebih akurat tidak dapat diinstal. Lihat golang sebagai contoh di mana beberapa arsitektur memerlukan pembuatan biner dari paket sumber upstream dan beberapa hanya mengunduh rilis biner.
Untuk gambar dasar seperti debian diperlukan Dockerfile yang berbeda dan membangun konteks untuk ADD biner khusus arsitektur dan ini merupakan pengecualian yang valid untuk hal di atas. Karena gambar-gambar ini menggunakan Tags yang sama, gambar-gambar tersebut harus berada dalam entri yang sama. Gunakan bidang khusus arsitektur untuk GitRepo , GitFetch , GitCommit , dan Directory , yang merupakan arsitektur yang digabungkan dengan tanda hubung ( - ) dan bidang tersebut (misalnya arm32v7-GitCommit ). Arsitektur apa pun yang tidak memiliki bidang khusus arsitektur akan menggunakan bidang default (mis. tidak ada arm32v7-Directory yang berarti Directory akan digunakan untuk arm32v7 ). Lihat file debian atau ubuntu di perpustakaan sebagai contoh. Berikut contoh 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
Lihat bagian format instruksi untuk informasi lebih lanjut tentang format file perpustakaan.
Mengusulkan citra resmi yang baru tidak boleh dianggap enteng. Kami mengharapkan dan memerlukan komitmen untuk menjaga citra Anda (termasuk dan terutama pembaruan tepat waktu, sebagaimana disebutkan di atas).
File definisi perpustakaan adalah file teks biasa yang ditemukan di direktori library/ dari repositori official-images . Setiap file perpustakaan mengontrol kumpulan tag gambar "yang didukung" saat ini yang muncul di deskripsi Docker Hub. Tag yang dihapus dari file perpustakaan tidak dihapus dari Docker Hub, sehingga versi lama dapat terus tersedia untuk digunakan, namun tidak dikelola oleh upstream atau pengelola image resmi. Tag dalam file perpustakaan hanya dibuat melalui pembaruan pada file perpustakaan tersebut atau sebagai akibat dari pembaruan gambar dasarnya (misalnya, gambar FROM debian:bookworm akan dibuat ulang ketika debian:bookworm dibuat). Hanya apa yang ada di file perpustakaan yang akan dibangun kembali ketika basis memiliki pembaruan.
Mengingat kebijakan ini, ada baiknya memperjelas beberapa kasus: versi yang diisi ulang, kandidat rilis, dan pembangunan integrasi berkelanjutan. Ketika repositori baru diusulkan, biasanya menyertakan beberapa versi lama yang tidak didukung dalam permintaan penarikan awal dengan perjanjian untuk menghapusnya segera setelah penerimaan. Jangan bingung membedakan hal ini dengan arsip sejarah komprehensif yang tidak dimaksudkan. Kasus umum lainnya di mana istilah "didukung" sedikit diperluas adalah dengan kandidat rilis. Kandidat pelepasliaran sebenarnya hanyalah sebuah konvensi penamaan untuk apa yang diperkirakan akan berumur pendek, jadi mereka benar-benar dapat diterima dan dianjurkan. Berbeda dengan kandidat rilis, build integrasi berkelanjutan yang memiliki siklus rilis otomatis sepenuhnya berdasarkan penerapan kode atau jadwal rutin tidaklah tepat.
Sangat disarankan agar Anda menelusuri beberapa konten library/ file yang ada (dan riwayat untuk merasakan perubahannya seiring waktu) sebelum membuat yang baru agar terbiasa dengan konvensi yang berlaku dan lebih lanjut membantu menyederhanakan proses peninjauan (jadi agar kita dapat fokus pada konten daripada format esoteris atau penggunaan/penamaan tag).
Nama file dari file definisi akan menentukan nama repositori gambar yang dibuatnya di Docker Hub. Misalnya, file library/ubuntu akan membuat tag di repositori ubuntu .
Tag repositori harus mencerminkan versi atau variasi upstream. Misalnya, Ubuntu 14.04 juga dikenal sebagai Ubuntu Trusty Tahr, namun seringkali hanya sebagai Ubuntu Trusty (terutama dalam penggunaannya), jadi ubuntu:14.04 (nomor versi) dan ubuntu:trusty (nama versi) adalah alias yang sesuai untuk konten gambar yang sama. Di Docker, tag latest adalah kasus khusus, tetapi istilahnya agak keliru; latest sebenarnya adalah tag "default". Ketika seseorang melakukan docker run xyz , Docker menafsirkannya sebagai docker run xyz:latest . Mengingat latar belakang tersebut, tidak ada tag lain yang pernah berisi string latest , karena string tersebut bukanlah sesuatu yang diharapkan atau didorong oleh pengguna untuk benar-benar diketik (yaitu, xyz:latest harus digunakan hanya sebagai xyz ). Dengan kata lain, memiliki alias untuk "rilis XYZ seri 2.2 tertinggi" seharusnya xyz:2.2 , bukan xyz:2.2-latest . Demikian pula, jika ada varian Alpine dari xyz:latest , maka harus diberi nama alias xyz:alpine , bukan xyz:alpine-latest atau xyz:latest-alpine .
Sangat disarankan agar tag nomor versi diberi alias yang memudahkan pengguna untuk tetap mengikuti rilis "terbaru" dari seri tertentu. Misalnya, mengingat Perangkat Lunak XYZ versi 2.3.7 dan 2.2.4 yang saat ini didukung, alias yang disarankan masing-masing adalah Tags: 2.3.7, 2.3, 2, latest dan Tags: 2.2.4, 2.2 . Dalam contoh ini, pengguna dapat menggunakan xyz:2.2 untuk dengan mudah menggunakan rilis patch terbaru dari seri 2.2, atau xyz:2 jika diperlukan lebih sedikit granularitas (Python adalah contoh bagus yang jelas berguna -- python:2 dan python:3 sangat berbeda, dan dapat dianggap sebagai tag latest untuk setiap jalur rilis utama Python).
Seperti dijelaskan di atas, latest benar-benar "default", jadi gambar aliasnya harus mencerminkan versi atau variasi perangkat lunak mana yang harus digunakan pengguna jika mereka tidak tahu atau tidak peduli versi mana yang mereka gunakan. Dengan menggunakan Ubuntu sebagai contoh, ubuntu:latest menunjuk ke rilis LTS terbaru, karena itulah yang seharusnya digunakan oleh sebagian besar pengguna jika mereka menginginkan Ubuntu tetapi tidak tahu atau tidak peduli versi yang mana (terutama mengingat versi tersebut akan menjadi versi terbarunya). rilis paling "stabil" dan didukung dengan baik pada waktu tertentu).
Format file manifes secara resmi didasarkan pada RFC 2822, dan oleh karena itu pasti sudah familiar bagi orang-orang yang sudah familiar dengan "header" dari banyak protokol/format internet populer seperti HTTP atau email.
Penambahan utama terinspirasi oleh cara Debian umumnya menggunakan 2822 -- yaitu, baris yang dimulai dengan # diabaikan dan "entri" dipisahkan oleh baris kosong.
Entri pertama adalah metadata "global" untuk gambar tersebut. Satu-satunya bidang yang diperlukan dalam entri global adalah Maintainers , yang nilainya dipisahkan koma dalam format Name <email> (@github) atau Name (@github) . Bidang apa pun yang ditentukan dalam entri global akan menjadi default untuk entri lainnya dan dapat diganti dalam entri individual.
# 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 akan mengambil kode dari repositori Git ( GitRepo ) pada komit yang ditentukan ( GitCommit ). Jika komit yang direferensikan tidak tersedia dengan mengambil master dari GitRepo terkait, maka perlu memberikan nilai untuk GitFetch untuk memberi tahu Bashbrew referensi apa yang harus diambil untuk mendapatkan komit yang diperlukan.
Gambar yang dibangun akan diberi tag sebagai <manifest-filename>:<tag> (yaitu, library/golang dengan nilai Tags 1.6, 1, latest akan membuat tag golang:1.6 , golang:1 , dan golang:latest ).
Secara opsional, jika Directory ada, Bashbrew akan mencari Dockerfile di dalam subdirektori yang ditentukan, bukan di root (dan Directory akan digunakan sebagai "konteks" untuk build, bukan di repositori tingkat atas). Jika File ada, nama file yang ditentukan, bukan Dockerfile akan digunakan.
Lihat bagian multi-lengkungan untuk detail tentang cara menentukan GitRepo , GitFetch , GitCommit , atau Directory yang berbeda untuk arsitektur tertentu.
library/ . Namanya akan menjadi nama repositori Anda di Hub. Bashbrew ( bashbrew ) adalah alat untuk mengkloning, membuat, menandai, dan mendorong image resmi Docker. Lihat README Bashbrew untuk informasi lebih lanjut.
