Moby: Gambar [repo publik] harus menggunakan kompresi tinggi

Saat kami melakukannya, kami mungkin juga mengaktifkan kompresi tinggi setiap kali buruh pelabuhan membuat tarball. Misalnya. 'dorongan buruh pelabuhan' dan 'ekspor buruh pelabuhan'.

Menggunakan kompresi yang lebih tinggi untuk semua operasi yang membuat tarball akan sangat bagus.

Pengembaliannya cukup signifikan dari waktu ke waktu dalam hal jumlah penyimpanan yang dibutuhkan pada S3 dan lalu lintas jaringan.

Saya pikir hanya perubahan ini yang diperlukan untuk mulai menggunakan kompresi tinggi untuk semua gambar baru di registri:
registry.go:

 // FIXME: Don't do this :D. Check the S3 requierement and implement chunks of 5MB
 // FIXME2: I won't stress it enough, DON'T DO THIS! very high priority
- layerData2, err := Tar(path.Join(graph.Root, img.Id, "layer"), Gzip)
- layerData, err := Tar(path.Join(graph.Root, img.Id, "layer"), Gzip)
+ layerData2, err := Tar(path.Join(graph.Root, img.Id, "layer"), Bzip2)
+ layerData, err := Tar(path.Join(graph.Root, img.Id, "layer"), Bzip2)

Jangan gunakan bzip2: gunakan lzma/xz sebagai gantinya. xc lebih cepat dari bzip2 dan mencapai kompresi yang lebih baik; dan bahkan memiliki mode "ekstrim" yang mencapai kompresi yang lebih ketat (tetapi kemudian membuatnya lebih lambat).

Lihat misalnya http://pokecraft.first-world.info/wiki/Quick_Benchmark :_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO

Juga, saya tidak dapat memeriksa sumbernya, tetapi kita jelas harus memastikan bahwa hash layer dilakukan pada tar yang tidak dikompresi.

Tidak ada lapisan hash sekarang, ID gambar dihitung secara acak. aku ingin
untuk mengembalikan ID yang dihasilkan konten dan ya, itu membutuhkan tar-aware
checksum.

Pada hari Minggu, 31 Maret 2013, Jérôme Petazzoni menulis:

Jangan gunakan bzip2: gunakan lzma/xz sebagai gantinya. xc lebih cepat dari bzip2 dan
mencapai kompresi yang lebih baik; dan bahkan memiliki mode "ekstrim" yang dicapai
kompresi bahkan lebih ketat (tapi kemudian membuatnya lebih lambat).

Lihat misalnya
http://pokecraft.first-world.info/wiki/Quick_Benchmark :_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO

Juga, saya tidak dapat memeriksa sumbernya, tetapi kami jelas harus memastikan
bahwa hash lapisan dilakukan pada tar yang tidak terkompresi.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/194#issuecomment -15697513
.

Saya telah melakukan beberapa tes dengan gambar pybuilder:

468 MB pybuilder.tar
221 MB pybuilder.tar.gz - 47% of the original size
208 MB pybuilder.tar.bz2 - 44% of the original size
180 MB pybuilder.tar.xz - 38% of the original size

Gambar terkompresi xz lzma2 14% lebih kecil dari gambar terkompresi bzip2.

Gambar lain menunjukkan penurunan ukuran yang serupa. Beberapa bahkan turun hingga 30% dari ukuran aslinya.

Catatan: kita juga harus memperbarui dependensi buruh pelabuhan dan instruksi instalasi untuk memberi tahu orang-orang agar menginstal xz .

Poin bonus jika buruh pelabuhan memastikan bahwa xz diinstal saat memulai, untuk mendapatkan pesan kesalahan informatif daripada kesalahan tar kabalistik (haruskah itu menjadi masalah lain?)

Ketergantungan ekstra jelas merupakan -1. Apakah _benar-benar_ sepadan dengan masalahnya dibandingkan dengan bzip2 -9?

xz tidak diperlukan. bsdtar memiliki dukungan asli untuk kompresi xz dan tidak memerlukan xz dari xz-utils, atau apa pun.

Saya baru saja memverifikasi ini dengan menggunakan bsdtar untuk mengompres dalam format xz, menjalankan xz untuk memastikan itu tidak ada dan kemudian menginstal xz-utils untuk mengekstrak arsip. Semuanya bekerja.

Jadi tidak ada yang perlu diperingatkan, selain tentang ketidakhadiran bsdtar.

Luar biasa.

Pada hari Senin, 1 April 2013 pukul 10:26, unclejack [email protected] menulis:

xz tidak diperlukan. bsdtar memiliki dukungan asli untuk kompresi xz dan itu
tidak perlu xz dari xz-utils, atau apa pun.

Saya baru saja memverifikasi ini dengan menggunakan bsdtar untuk mengompres dalam format xz, menjalankan xz
untuk memastikan itu tidak ada dan kemudian instal xz-utils untuk mengekstrak
Arsip. Semuanya bekerja.

Jadi tidak ada yang perlu diperingatkan, selain tentang ketidakhadiran bsdtar.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/194#issuecomment -15725699
.

Jika kita ingin menghilangkan ketergantungan bsdtar, kita bisa. Cukup tukar archive/tar dan http://godoc.org/code.google.com/p/lzma alih-alih keluar. Mungkin masuk akal untuk menunggu hingga registri mendukung unggahan streaming untuk melakukan ini, tetapi itu tidak diperlukan.

arsip/tar tidak mendukung tarring dan untarring aktual pada sistem file.
Hanya penguraian/pengodean aliran tar itu sendiri.

Ada juga deteksi otomatis kompresi yang sangat berguna
fitur.

Pada hari Senin, 1 April 2013, Jonathan Rudenberg menulis:

Jika kita ingin menghilangkan ketergantungan bsdtar, kita bisa. Tukar saja di archive/ tarhttp://tip.golang.org/pkg/archive/tar/and
http://godoc.org/code.google.com/p/lzma alih-alih keluar. Mungkin
masuk akal untuk menunggu hingga registri mendukung unggahan streaming untuk melakukan ini,
tapi itu tidak wajib.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/194#issuecomment -15726255
.

@shykes Ya, pada dasarnya itu akan membutuhkan implementasi ulang file walking dan pembuatan header tar yang dilakukan tar/bsdtar.

Perubahan yang disebutkan dalam masalah ini dibuat oleh permintaan tarik #308.

Masalah lain dibuat untuk menambahkan hashing untuk konten lapisan dan id induk saat membuat id gambar. Masalahnya adalah #310.