Anda Merantai mereka :)

jadi misalnya, jika Anda memiliki satu Dockerfile yang menyiapkan klien postgres generik dan env aplikasi python generik, Anda memberi tag pada hasil build itu (misalnya mygenericenv ), dan kemudian Dockerfile berikutnya menggunakan FROM mygenericenv .

untuk misalnya

## Dockerfile.genericwebapp might have FROM ubuntu
cat Dockerfile.genericwebapp | docker build -t genericwebapp -
## Dockerfile.genericpython-web would have FROM genericwebapp
cat Dockerfile.genericpython-web | docker build -t genericpython-web -
## and then this specific app i'm testing might have a docker file that containers FROM genericpython-web
docker build -t thisapp .

Saya dapat melihat bagaimana melakukannya, yaitu genericA --> specificA tetapi apakah ada cara untuk melakukan sesuatu seperti:

genericA --
            \
             ---> specificAB
            /
genericB --

?

Tidak melalui cara resmi apa pun, tetapi beberapa orang beruntung memodifikasi hierarki gambar secara manual untuk mencapai ini (tetapi jika Anda melakukan ini, Anda melakukannya dengan risiko Anda sendiri, dan Anda dapat menyimpan semua bagian).

Alasan ini tidak akan didukung secara resmi adalah karena bayangkan saya ingin mengambil "ubuntu" dan mencangkokkan "centos" di atasnya. Akan ada banyak konflik menyenangkan yang menyebabkan mimpi buruk dukungan, jadi jika Anda ingin melakukan hal-hal seperti itu, Anda sendirian.

Oke saya mengerti mengapa. Saya mencari blok fungsionalitas yang dapat dikomposisi tetapi mungkin ini bukan kasus penggunaan Docker ... sepertinya saya harus menggunakannya untuk mengatur wadah mentah kemudian menjalankan sesuatu seperti ansible atau saltstack di atas untuk mengonfigurasi perangkat lunak di dalamnya.

Gagasan di balik wadah adalah bahwa unit terkecil dari komposisi nyata adalah wadah. Artinya, wadah adalah hal terkecil yang dapat Anda hasilkan terlebih dahulu, tidak tahu dengan apa lagi ia akan digabungkan, dan memiliki jaminan yang kuat tentang bagaimana ia akan berperilaku dan berinteraksi dengan komponen lain.

Oleh karena itu, setiap unit yang lebih kecil dari wadah - baik itu skrip ruby ​​​​atau shell, pohon sumber c++, biner sendiri, satu set file konfigurasi, paket sistem, dll. - tidak dapat disusun dengan aman, karena akan berperilaku sangat berbeda tergantung pada dependensi build, dependensi runtime, dan komponen lain apa yang menjadi bagian dari komposisi.

Kenyataan itu sebagian dapat ditutupi dengan kekerasan. Brute force semacam itu bisa pragmatis dan "cukup baik" (Makefile raksasa yang secara otomatis mendeteksi semuanya untuk build aplikasi Anda yang lebih portabel) atau terlalu berlebihan ("mari kita buat model terlebih dahulu setiap kemungkinan permutasi dari setiap ketergantungan dan interferensi antar komponen, dan ekspresikan mereka dalam abstraksi tingkat tinggi!")

Saat Anda mengandalkan Ansible, Chef, atau manajemen konfigurasi lainnya untuk membuat "komponen yang dapat dikomposisi", Anda mengandalkan abstraksi yang bocor: komponen ini, pada kenyataannya, tidak dapat dikomposisi. Dari satu sistem ke sistem berikutnya mereka akan menghasilkan bangunan yang berperilaku berbeda dalam sejuta cara. Semua abstraksi ekstra pada akhirnya akan memberi Anda sangat sedikit.

Saran saya adalah fokus pada 2 hal: 1) kode sumber, dan 2) wadah yang dapat dijalankan. Ini adalah satu-satunya 2 poin komposisi yang dapat diandalkan.

Pada Minggu, 29 Des 2013 pukul 13:46, anentropic [email protected]
menulis:

Oke saya mengerti mengapa. Saya mencari blok fungsionalitas yang dapat dikomposisi tetapi mungkin ini bukan kasus penggunaan Docker ... sepertinya saya harus menggunakannya untuk mengatur wadah mentah kemudian menjalankan sesuatu seperti ansible atau saltstack di atas untuk mengonfigurasi perangkat lunak di dalamnya.

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/dotcloud/docker/issues/3378#issuecomment -31326172

Terima kasih telah memberikan lebih banyak perspektif.

Jadi Anda mengatakan bahwa untuk menggunakan kembali bagian dari Dockerfiles, satu-satunya alat yang tersedia adalah salin dan tempel? Berasal dari sudut pandang 'dev' daripada 'ops', rasanya agak salah.

Mungkin itu kesalahan memiliki indeks publik gambar, itu membuatnya tampak seperti Anda dapat membagikan blok bangunan yang dapat digunakan kembali yang secara samar-samar dianalogikan dengan resep Chef, tetapi pengalaman saya sejauh ini tidak berguna karena:
a) untuk sebagian besar gambar tidak ada info tentang apa yang dilakukannya dan apa yang ada di dalamnya
b) dokumen mendorong melakukan pekerjaan Anda ke indeks (sehingga Anda nanti dapat menariknya) meskipun apa yang Anda buat mungkin tidak berguna bagi orang lain, saya kira sebagian besar dari apa yang ada di sana mungkin tidak layak untuk dibagikan

Saya merasa dokumen tidak benar-benar memandu Anda untuk menggunakan Docker dengan cara yang masuk akal saat ini

@anentropic Cara yang tepat untuk melakukan ini dengan Dockerfiles adalah dengan membangun banyak gambar dengan beberapa Dockerfiles.
Berikut ini contohnya: Dockerfile 1 membuat gambar generik di atas gambar dasar Ubuntu, Dockerfile 2 menggunakan gambar yang dihasilkan dari Dockerfile 1 untuk membuat gambar untuk server database, Dockerfile 3 menggunakan gambar server database dan mengonfigurasinya untuk peran khusus .

docker build seharusnya cukup mudah dijalankan dan kerumitan yang tidak perlu tidak boleh ditambahkan.

Indeks publik gambar sangat berguna. Gambar Docker biasanya dimaksudkan untuk menjalankan satu layanan atau sekelompok layanan yang tidak dapat berjalan dalam wadah terpisah. Anda biasanya dapat menarik gambar, menjalankannya dan mendapatkan beberapa perangkat lunak yang berguna dan berjalan tanpa banyak usaha.

Dimengerti... jadi dalam skenario yang saya uraikan dengan seni ascii di atas, cara Docker adalah:

• mulai dengan Dockerfiles untuk gambar independen GenericA dan GenericB
• untuk membuat gambar SpecificAB Saya akan menyalin dan menempelkan konten Dockerfile GenericB ke dalam Dockerfile baru yang dimulai dengan: FROM GenericA

Masalah yang saya lihat adalah jika 'resep' (meminjam istilah Chef) untuk GenericB cukup rumit dan memiliki banyak langkah, tidak mungkin saya dapat membagikan info ini, kecuali dengan menerbitkan Dockerfile _to Github_ jadi bahwa orang lain dapat _menyalin dan menempel_ bagian yang relevan ke dalam file Docker mereka sendiri.

Sudahkah Anda mencoba menggunakan indeks publik? Misalnya, saya melakukan pencarian untuk "postgres"... bagaimana cara menilai kegunaan (atau membedakan dengan cara apa pun) gambar seperti ini:

• https://index.docker.io/u/cthulhuology/postgres/
• https://index.docker.io/u/alvin/postgres/
• https://index.docker.io/u/antihero/postgres/
• https://index.docker.io/u/dbraden/postgres/

?

Nilai apa yang diberikan ini ketika satu-satunya cara untuk memastikan saya telah menyiapkan server Postgres seperti yang saya inginkan, pada gambar dasar tertentu, tanpa ada yang tersembunyi di sana, adalah dengan membuatnya sendiri dari awal.

Saya dapat melihat nilai dari beberapa gambar dasar yang 'diberkati secara resmi' dalam indeks publik. Saya dapat melihat nilai memiliki indeks pribadi dari gambar kustom saya sendiri yang siap diambil.

Tetapi tampaknya memalukan bahwa tidak ada cara (selain salin & tempel) untuk membagikan rangkaian perintah di Dockerfile sebagai resep... seperti saran untuk perintah 'sertakan' yang ditolak di sini https://github .com/dotcloud/docker/pull/2108

@anentropic Anda dapat menggunakan gambar tepercaya dan Anda juga dapat menemukan postgres Dockerfile untuk membuat gambar sendiri.

Gambar biasanya lebih berguna saat Anda menyesuaikan Dockerfile untuk memastikannya sesuai dengan kebutuhan Anda. Itulah mengapa Anda menemukan bahwa lebih banyak pengguna telah mengunggah gambar untuk perangkat lunak yang sama ke registri.

Gambar spesifik yang ada seperti gambar postgres mungkin tidak memenuhi kebutuhan khusus Anda, tetapi ada juga gambar dasar dan ini dapat langsung digunakan untuk membangun sesuatu yang berguna bagi Anda.

Gambar dasar seperti ubuntu , centos dan beberapa gambar dari stackbrew/* adalah gambar yang dapat Anda gunakan untuk membuat apa yang Anda butuhkan.

Contoh gambar siap pakai yang bagus adalah stackbrew/registry . Gambar ini memungkinkan Anda bermain-main dengan registri Docker pribadi segera setelah docker pull stackbrew/registry dan docker run -p stackbrew/registry selesai dieksekusi.

Tujuan Docker adalah untuk membantu penerapan dan mempersiapkan lingkungan tempat perangkat lunak Anda berjalan. Ini berarti bahwa build bersifat linier dan hanya dilakukan selama build awal, tetapi Anda akan menjalankan perangkat lunak yang sama persis setiap saat.

Sistem manajemen konfigurasi memungkinkan Anda untuk melakukan sesuatu yang lebih atau menggunakan beberapa trik lain, tetapi mereka tidak "tidak dapat diubah" dan Anda dapat memiliki dua host yang memiliki perbedaan halus yang tidak diambil oleh perangkat lunak manajemen konfigurasi.

Benci untuk necro utas lama, tetapi ingin menawarkan sesuatu yang IMHO membantu menyelesaikan masalah poster asli dan dapat membantu orang lain mencari solusi serupa untuk masalah ini di sini.

Mari kita asumsikan untuk kesederhanaan bahwa mereka semua menggunakan gambar dasar yang sama R . Bayangkan saya memiliki layanan A dan layanan B . Saya ingin mereka dalam gambar Docker terpisah dan keduanya pada gambar Docker yang sama.

Tulis skrip untuk menginstal layanan A dan tulis skrip terpisah untuk menginstal layanan B . Kemudian miliki git repo dengan skrip untuk A dan satu lagi untuk skrip B . Buat git repo untuk ketiga image Docker yang akan dibangun. Masing-masing berisi submodul git dengan skrip instalasi yang akan digunakan. Setiap Dockerfile hanya akan ADD skrip penginstalan dan kemudian RUN skrip penginstalan dan melakukan ini untuk satu atau kedua skrip. Jika Anda ingin menghapus skrip dari gambar, tempelkan setelah menjalankannya.

Dengan cara ini ada satu salinan dari setiap skrip instal dan gambar buruh pelabuhan apa pun yang Anda inginkan untuk menggunakannya. Ini menghindari penyalinan kode yang tidak perlu dan menjaga beban pemeliharaan tetap minimal. Satu-satunya upaya duplikasi adalah meningkatkan komit yang digunakan oleh submodul, yang secara signifikan lebih baik daripada alternatifnya dan mungkin dapat diotomatisasi.

Saya pikir saya salah mengerti cara kerjanya, jadi saya membalas untuk mendapatkan klarifikasi. Saya ingin menggunakan Ubuntu 11 dengan gambar buruh pelabuhan Selenium resmi. Mereka menggunakan Ubuntu 15.

https://github.com/SeleniumHQ/docker-selenium/blob/master/Base/Dockerfile

Apa cara yang benar bagi saya untuk melakukan ini? Untuk mengkloning repo itu dan mengedit semua file untuk mengatakan Ubuntu 11 dan bukan 15? Ini tidak mungkin benar, kan? Ini berarti bahwa setiap orang yang tidak setuju dengan aspek apa pun dari gambar resmi tidak dapat menggunakannya tanpa menduplikasi kodenya. Saya pikir saya salah, ada yang bisa menjelaskan? Apa cara yang tepat untuk menggunakan gambar Selenium resmi dengan Ubuntu 11?

@rjurney ya, begitulah cara kerjanya; dalam contoh Anda, seluruh Dockerfile dikembangkan dengan mempertimbangkan ubuntu:15.04 ; apakah paket-paket itu tersedia di ubuntu:11? Apakah mereka bekerja? Apakah selenium berjalan pada mereka? Kemungkinannya adalah modifikasi perlu dilakukan di Dockerfile agar dapat berfungsi di versi Ubuntu yang lain.

"menukar" gambar dasar dari gambar yang ada juga tidak akan berfungsi, karena Docker hanya menyimpan _differences_ antara gambar dasar dan gambar. Oleh karena itu, menggunakan gambar dasar yang berbeda menghasilkan hasil yang tidak terduga (misalnya, "hapus file X", di mana "file X" ada di gambar dasar asli, tetapi tidak ada di gambar dasar yang Anda pilih). Juga, paket/binari dalam gambar yang dibangun "di atas" dari gambar dasar, adalah paket yang dibuat untuk versi _itu_, binari tersebut mungkin tidak kompatibel dengan gambar dasar yang berbeda.

Ini berarti bahwa setiap orang yang tidak setuju dengan aspek apa pun dari gambar resmi tidak dapat menggunakannya tanpa menduplikasi kode untuk gambar tersebut.

Ya. Gambar resmi didukung oleh pengelola gambar tersebut (yang dalam hal ini adalah pengelola Selenium). Jika menurut Anda perubahan diperlukan pada gambar-gambar itu, cara terbaik adalah membuka permintaan fitur di repositori mereka. Jika permintaan fitur tersebut tidak diterima, Anda mungkin harus membuat versi Anda sendiri.

(Perhatikan juga bahwa tidak ada gambar resmi ubuntu:11 )

Di dunia perangkat lunak lainnya, pewarisan tunggal tidak dilihat sebagai
cukup untuk mengekspresikan semantik yang dibutuhkan secara wajar. Ini mengarah ke banyak kode
duplikasi, yang akan dianggap sebagai bug. Mengapa ini terlihat sebagai
diterima untuk buruh pelabuhan? Bahkan jika Anda sedang membangun satu layanan pada satu waktu,
komposisi diperlukan di tingkat sistem operasi. Saya tidak bermaksud untuk mengalahkan
kuda mati, tetapi batas ini tampaknya sedikit ekstrem. Mungkinkah itu lebih baik?
dinyatakan sebagai praktik terbaik? Sebagai hasil dari ketatnya ini
keputusan, seseorang akan membangun alat yang melakukan komposisi atau banyak
pewarisan dan mengekspresikannya melalui pewarisan tunggal dan penggandaan.
Memiliki ini di luar buruh pelabuhan yang tepat tidak akan melayani komunitas buruh pelabuhan.

Pada hari Rabu, 9 Desember 2015, Sebastiaan van Stijn <
[email protected]> menulis:

@rjurney https://github.com/rjurney ya, begitulah cara kerjanya; di
contoh Anda, seluruh Dockerfile dikembangkan dengan mempertimbangkan ubuntu:15.04 ;
apakah paket-paket itu tersedia di ubuntu:11? Apakah mereka bekerja? Apakah selenium berjalan?
pada mereka? Kemungkinannya adalah modifikasi perlu dilakukan di Dockerfile
untuk membuatnya bekerja pada versi lain dari Ubuntu.

"menukar" gambar dasar dari gambar yang ada juga tidak akan berfungsi, karena
Docker hanya menyimpan _differences_ antara gambar dasar dan
gambar. Oleh karena itu, menggunakan gambar dasar yang berbeda mengarah pada hal yang tidak terduga
hasil (misalnya, "hapus file X", di mana "file X" ada di basis aslinya
gambar, tetapi tidak pada gambar dasar yang Anda pilih). Juga, paket/binari
dalam gambar yang membangun "di atas" gambar dasar, adalah paket yang dibangun
untuk versi _that_, binari tersebut mungkin tidak kompatibel dengan yang lain
gambar dasar.

Ini berarti bahwa setiap orang yang tidak setuju dengan aspek apa pun
gambar resmi tidak dapat menggunakannya tanpa menduplikasi kode untuknya

Ya. Gambar resmi didukung oleh pengelola gambar tersebut
(yang dalam hal ini, adalah pengelola Selenium). Jika Anda berpikir perubahan
diperlukan untuk gambar-gambar itu, cara terbaik adalah membuka permintaan fitur di
gudang mereka. Jika permintaan fitur itu tidak diterima, Anda harus
mungkin membangun versi Anda sendiri.

(Perhatikan juga bahwa tidak ada gambar resmi ubuntu:11)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3378#issuecomment -163188299.

Russell Jurney twitter.com/rjurney russell. [email protected] relato.io

@rjurney pewarisan berganda juga sangat kompleks dan bukan hanya sesuatu yang baru saja Anda tambahkan tanpa memikirkan konsekuensi, kasus sudut, dan ketidakcocokan.

12749 adalah upaya terbaru untuk menambahkan fungsionalitas seperti itu -- akhirnya ditolak karena ada pekerjaan lain yang harus diselesaikan terlebih dahulu.

Ada banyak pekerjaan yang dilakukan pada builder, termasuk mengaktifkan build yang digerakkan oleh klien yang dapat membukanya sedikit.

Dockerfiles warisan tunggal berfungsi untuk sebagian besar kasus penggunaan (luas), karena itu tidak perlu terburu-buru untuk meningkatkan ini. Itu perlu dilakukan dengan benar dan sengaja.
Dan berdasarkan komentar Anda di atas, saya akan mengatakan Anda sebenarnya tidak memerlukan banyak pewarisan, hanya cara untuk menentukan gambar dasar yang dijalankan oleh Dockerfile tanpa menduplikasi kode yang ada.

Itu akan memenuhi kebutuhan saya, ya. Mampu memodifikasi beberapa properti dari
rantai file docker.

Oke, senang mendengar Anda berada di atas ini. Terima kasih atas kesabaran Anda :)

Pada hari Rabu, 9 Des 2015 jam 09:59, Brian Goff [email protected] menulis:

@rjurney https://github.com/rjurney pewarisan berganda juga
sangat kompleks dan bukan hanya sesuatu yang baru saja Anda tambahkan tanpa berpikir
untuk konsekuensi, kasus sudut, dan ketidakcocokan.

12749 https://github.com/docker/docker/pull/12749 adalah yang terbaru

mencoba menambahkan fungsi tersebut -- akhirnya ditolak karena ada
pekerjaan lain yang harus diselesaikan terlebih dahulu.
Ada banyak pekerjaan yang dilakukan pada pembuatnya, termasuk mengaktifkan
build yang digerakkan oleh klien yang dapat membuka ini sedikit.

Dockerfiles warisan tunggal berfungsi untuk sebagian besar kasus penggunaan (luas),
karena itu tidak ada terburu-buru untuk meningkatkan ini. Itu perlu dilakukan dengan benar dan
dengan sengaja.
Dan berdasarkan komentar Anda di atas, saya akan mengatakan Anda sebenarnya tidak membutuhkan banyak
warisan, hanya cara untuk menentukan gambar dasar yang menjalankan Dockerfile
melawan tanpa menduplikasi kode yang ada.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3378#issuecomment -163340165.

Russell Jurney twitter.com/rjurney russell. [email protected] relato.io

@rjurney Di mana Anda mendapatkan informasi Anda. Sepengetahuan saya, Java tidak pernah memiliki banyak warisan, dan tidak akan pernah. Saya yakin hal yang sama berlaku untuk banyak bahasa. Banyak yang menganggap pewarisan berganda sangat berbahaya, karena dapat menghasilkan kode yang hampir mustahil untuk diprediksi. Hal yang sama akan berlaku untuk wadah buruh pelabuhan.

Seperti yang saya lihat, yang kita butuhkan untuk buruh pelabuhan bukanlah konsep pewarisan berganda, tetapi konsep dependensi yang disertakan atau eksternal. misalnya Anda dapat memasang wadah pada waktu berjalan. Yang benar-benar dibutuhkan adalah cara untuk menyamakan dengan gambar. Jadi, misalnya, Anda dapat memiliki gambar yang didefinisikan berdasarkan Fedora 22, dan memasang gambar Oracle untuk menambahkan fungsionalitas basis data.

Ini dapat dilakukan dengan cukup berhasil saat menjalankan container, tetapi tidak ada sintaks untuk menentukannya dengan gambar. Jadi sampai run-time tidak mungkin buruh pelabuhan dapat mengetahui tentang dependensi ini atau mengelolanya untuk Anda.

Harap dicatat bahwa saya menyebutkan banyak pewarisan dan komposisi.
Komposisi adalah cara yang lebih disukai untuk melakukan ini, pasti.

Saya setuju dengan semua yang Anda katakan, jadi +1.

Pada hari Rabu, 9 Desember 2015, Bill C Riemers [email protected]
menulis:

@rjurney https://github.com/rjurney Di mana Anda mendapatkan informasi Anda.
Sepengetahuan saya, Java tidak pernah memiliki banyak warisan, dan tidak akan pernah.
Saya yakin hal yang sama berlaku untuk banyak bahasa. Banyak yang menganggap banyak
warisan sangat berbahaya, karena dapat mengakibatkan hampir tidak mungkin untuk
kode yang dapat diprediksi. Hal yang sama akan berlaku untuk wadah buruh pelabuhan.

Seperti yang saya lihat, yang kita butuhkan untuk buruh pelabuhan bukanlah konsep kelipatan
pewarisan, tetapi konsep termasuk atau dependensi eksternal. misalnya
Anda dapat memasang wadah pada waktu proses. Yang benar-benar dibutuhkan adalah cara untuk
setara dengan gambar. Jadi Anda bisa misalnya memiliki gambar itu
didefinisikan berdasarkan Fedora 22, dan pasang gambar oracle untuk ditambahkan
fungsionalitas basis data.

Ini dapat dilakukan dengan cukup berhasil saat menjalankan container, tetapi ada
hanya tidak ada sintaks untuk menentukannya dengan gambar. Jadi sampai run-time tidak ada
cara buruh pelabuhan dapat mengetahui tentang dependensi ini atau mengelolanya untuk
Anda.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3378#issuecomment -163351035.

Russell Jurney twitter.com/rjurney russell. [email protected] relato.io

Saya akan tutup mulut setelah ini, tetapi saya memasukkan kata-kata kasar ini dalam permintaan tarik yang disebutkan di atas alih-alih tiket ini, secara tidak sengaja. Jadi saya taruh di sini.

Seseorang akan membangun ini. Tidak menerima tarikan yang menambahkan INCLUDE akan menunda dan mengeksternalisasi fitur ini. Ini harus menjadi dasar keputusan di sini: haruskah ini di dalam buruh pelabuhan atau di luar buruh pelabuhan?

Sebuah contoh datang ke pikiran. Di Apache Pig, tim membuat keputusan untuk tidak menyertakan loop, meskipun banyak permintaan untuk mereka, karena diputuskan bahwa Pig harus bagus untuk aliran data DAG dan hanya itu. Sebagai gantinya, integrasi dibuat ke skrip skrip babi, sehingga Anda dapat mengulang skrip dari bahasa JVM apa pun. Perhatikan bahwa ini adalah keputusan sadar dan bahwa alternatif telah diupayakan. Ini adalah proses model menurut saya.

Contoh Babi lain muncul di benak... Pig Macros. Mereka tidak ada dan 'tidak babi' sampai seseorang (oke, saya) memulai utas tentang betapa jeleknya proyek babi besar mereka dan bahwa tidak ada cara untuk memperbaiki masalah ini tanpa membuat Babi dari alat eksternal, yaitu tidak diinginkan. Banyak orang menimpali, dan tim Babi menambahkan makro. Makro memungkinkan babi bersih, dan masyarakat diuntungkan.

Saya menyarankan agar Anda membahas keputusan tersebut secara langsung dan berdiskusi tentangnya, yang belum terjadi di sini, dan untuk dapat ditemukan mungkin ada di sini. Ini akan ada. Menggandakan skrip dalam bahasa khusus domain sangat buruk. Rakyat akan menuntutnya. Apakah fitur ini akan berada di dalam Docker atau di luar Docker? Bagaimana Anda akan memfasilitasi perilaku ini di luar buruh pelabuhan?

Maaf, saya mungkin kehilangan banyak konteks di milis, tetapi sebagai pengguna Docker baru... Saya merasa sangat ragu untuk melakukan banyak hal dengan Docker tanpa kemampuan untuk membuat file docker dari resep yang ada. Saya pergi ke jalan ini dengan Babi, dan itu hampir membunuh saya. Saya pikir banyak orang akan merasakan hal ini.

Jika ada yang peduli...

Presentasi setengah adopsi tentang loop dan makro di Pig: http://wiki.Apache.org/pig/TuringCompletePig
Pig Macro JIRA: https://issues.Apache.org/jira/browse/PIG-1793
Antarmuka API ke Pig JIRA: https://issues.Apache.org/jira/browse/PIG-1333
Salah satu yang ditolak mentah-mentah untuk menghormati Apache Hive... tambahkan SQL ke Pig: https://issues.Apache.org/jira/browse/PIG-824

Akhirnya, saya punya ide yang mungkin membuat perubahan ini mudah... bagaimana jika TERMASUK file tidak dapat mewarisi? yaitu Anda akan menghindari keberatan dengan menjaga hal-hal yang super sederhana. Tangani sisanya nanti karena lebih banyak yang dipelajari. Mungkin ada Dockerfile sederhana misalnya yang menginstal pra-persyaratan dan binari, dan menyiapkan daemon untuk MySQL di Ubuntu. Jika perlu, ini dapat diversi menurut versi Ubuntu dan MySQL. Secara pribadi, saya akan meretas utilitas untuk melakukan TERMASUK sederhana ini dan menggunakannya untuk mengatur file docker saya dengan cara ini. Saya tidak sabar untuk memesan dan menggunakan kembali kode saya.

+1 untuk ide TERMASUK. Meskipun saya percaya melarang pewarisan hanya akan mengubah masalah, karena sekarang Anda dapat memodifikasi gambar utama yang Anda warisi tetapi bukan gambar lain yang Anda sertakan. Pada dasarnya apa yang masuk akal jika Anda dapat menentukan gambar menjadi "termasuk" karena tidak memberikan hal-hal sistem operasi apa pun yang mungkin merusak hal-hal gambar dasar yang ada. Bendera ini harus disetel oleh proses pembuatan buruh pelabuhan dan akan mencegah gambar yang tidak ditandai secara memadai untuk disertakan. Dan maksud saya, mari kita hadapi itu. Jika Anda bermain dengan Dockerfiles, Anda mungkin bukan orang yang melihat mesinnya untuk hari pertama, jadi saya percaya bahwa meskipun masuk akal untuk mencegah pengguna akhir buruh pelabuhan melakukan hal-hal bodoh, harus ada sedikit lagi kebebasan untuk orang-orang yang benar-benar membuat gambar-gambar itu. Dan maksud saya serius, dapat memilih gambar dasar dan memasukkan semua hal yang saya inginkan ke dalamnya untuk menyediakan aplikasi saya akan sangat luar biasa.

+1 untuk TERMASUK. Saya hanya perlu gambar nginx dan ssh digabungkan menjadi satu. Mengapa ini harus begitu sulit?

Gagasan bahwa ini tidak diperlukan terus terang membingungkan sampai-sampai
tidak jujur. Sebagian besar pengguna akan menggunakan ini, jika dibuat. "Tambahkan ssh ke
ubuntu" dan "tambahkan nginx ke ubuntu" adalah tugas yang cukup umum yang dilakukan semua orang
tidak perlu mengulang. Apa yang sebenarnya dikatakan oleh markas besar buruh pelabuhan tentang ini adalah,
"Jelas dibutuhkan, tapi kami pikir itu akan menjadi terlalu jelek. Jadi kami berpura-pura." Dia
akan lebih baik jika Anda benar-benar bisa jujur ​​dan terbuka tentang hal ini.
Maaf jika saya cerewet.

Pada Sabtu, 23 Januari 2016 pukul 18.22, Vazy [email protected] menulis:

+1 untuk TERMASUK. Saya hanya perlu gambar nginx dan ssh digabungkan menjadi satu. Mengapa
apakah ini harus begitu sulit?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3378#issuecomment -174243875.

Russell Jurney twitter.com/rjurney russell. [email protected] relato.io

@rjurney mari kita tunggu build spin-out ; karena dengan cara ini, akan ada lebih dari satu cara untuk membuat gambar (dan dengan demikian pembuat kustom dapat muncul yang melakukan itu). Salah satu alasan pengelola buruh pelabuhan (berfungsi atau tidak bekerja untuk Docker) sangat berhati-hati tentang hal itu, adalah karena itu akan menambah kompleksitas di mana kita ingin menambahkan fleksibilitas dan kesederhanaan. Dengan mengekstrak pembangun, kita akan memiliki pemisahan perhatian yang lebih baik (antara membangun gambar dan menjalankannya) dan banyak kasus penggunaan akan lebih bebas diimplementasikan di pembuat kustom.

Di sini sekali lagi, apakah Anda mendorong ini keluar dari proyek? Suara khusus... tidak
default, termasuk cara. Padahal, termasuk adalah kebutuhan sederhana yang
kebanyakan orang punya. Mengulangi diri sendiri adalah kompleksitas. Warisan hanya
kompleksitas. Termasuk mencocokkan kebutuhan semua orang dengan cara yang paling sederhana
mungkin.

Pada hari Minggu, 24 Januari 2016, Vincent Demeester [email protected]
menulis:

@rjurney https://github.com/rjurney mari kita tunggu build spin- outnya ;
karena dengan cara ini, akan ada lebih dari satu cara untuk membuat gambar (dan karenanya
pembuat kustom dapat muncul yang melakukan itu). Salah satu alasan buruh pelabuhan
pengelola (bekerja atau tidak bekerja untuk Docker) lincah tentang hal itu, adalah
karena itu akan menambah kerumitan di mana kami ingin menambahkan fleksibilitas dan
kesederhanaan. Dengan mengekstrak pembangun, kita akan memiliki pemisahan yang lebih baik dari
perhatian (antara membangun gambar dan menjalankannya) dan banyak kasus penggunaan
akan lebih bebas diimplementasikan di custom builder.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3378#issuecomment -174423973.

Russell Jurney twitter.com/rjurney russell. [email protected] relato.io

+1, menggabungkan gambar akan sangat berguna. Bayangkan kasus penggunaan C++ (tuhan melarang). Saya membangun imajinasi dengan boost, yang lain dengan mengatakan Qt, semua dengan kompiler yang sama, dll. Sekarang katakan saya ingin membangun aplikasi dengan boost dan Qt, saya hanya perlu menggabungkan keduanya dan presto - lingkungan dev siap. Ini akan sangat berguna.

Secara pribadi, saya merasa ini adalah masalah yang terlalu penting untuk tidak ditangani. Karena itu, kita perlu mendapatkan pemahaman yang baik tentang apa masalah dan ruang lingkupnya terlepas dari di mana penerapannya.

Jadi, saya melihat masalah ini disajikan dengan penggabungan.

1. Menangani konflik gabungan.
2. Menyelesaikan basis yang berbeda (Ubuntu dan CentOS).

Dengan yang pertama saya pikir jawaban sederhananya adalah jangan. Bagi saya kedengarannya rumit dan berpotensi bermasalah dan akan membutuhkan seperangkat alat untuk menyelesaikannya dan mungkin masih terlalu ajaib. Jadi, jika ini ditambahkan, konflik penggabungan seharusnya gagal. Saya kira itu bisa ditinjau kembali nanti, tapi sepertinya lebih banyak masalah daripada nilainya.

Untuk kasus kedua, sepertinya Anda bisa menambahkan batasan bahwa mereka berbagi beberapa lapisan dasar. Sekarang pertanyaannya menjadi berapa banyak yang cukup. Saya pikir jawaban yang benar ketika memulai adalah dua gambar yang digabungkan harus memiliki gambar FROM . Mungkin perlu ada lebih banyak kendala di sini, tetapi tidak jelas bagi saya bahwa kasus itu tidak akan termasuk dalam masalah 1, yang telah diselesaikan hanya dengan melarangnya.

Apakah ada masalah lain yang saya lewatkan di sini?

Saya pikir seharusnya tidak ada upaya untuk menggabungkan ... Saya tidak bisa melihat itu terjadi

Pendekatan yang lebih realistis mungkin merupakan jenis solusi templating, yaitu mengizinkan INCLUDE _fragment_ Dockerfile (yang tidak memiliki klausa FROM , hanya daftar perintah) ke dalam file Docker... fragmen dapat dibagikan, digunakan kembali, dan disertakan dengan Dockerfile gambar dasar apa pun yang kompatibel

http://docktitude.io

Saya benar-benar baru di Docker dan belajar dengan rendah hati. Tapi saya pikir poin utama Docker adalah membangun aplikasi _reusable_ yang sangat kecil untuk kemudian menggabungkannya dengan cara apa pun ke aplikasi akhir besar yang hebat seperti dalam aplikasi web. Jika demikian, IMHO pernyataan seperti INCLUDE adalah wajib.

@jmcejuela dalam banyak kasus "penggunaan kembali" membuat gambar yang didedikasikan untuk layanan tertentu, dan menggabungkan gambar/wadah tersebut untuk membentuk aplikasi Anda. Masing-masing komponen aplikasi Anda dapat digunakan kembali (mungkin, hanya konfigurasi wadah yang berbeda), tetapi cara Anda menggabungkannya membentuk aplikasi yang sebenarnya.

@thaJeztah saya mengerti, terima kasih.

Tetapi membuatnya konkret seperti yang diposting orang sebelumnya, katakanlah saya membangun aplikasi web yang menjalankan aplikasi scala (gambar A ), lalu buat server web dengan nginx (gambar B ), lalu miliki ssh (gambar C ), dan membutuhkan aplikasi python tambahan (gambar D ). Katakanlah saya telah membuat 4 Dockerfile untuk masing-masing. Bagaimana cara menggabungkannya dengan Docker untuk membuat aplikasi web terakhir saya (gambar E ?)

Saya hanya perlu cara sederhana untuk melakukan ini. Saya tidak peduli tentang perselisihan filosofi tentang pewarisan berganda, termasuk atau tidak, menulis atau tidak, dll. Meskipun tentu saja saya tidak ingin menyalin & menempel seperti yang diusulkan sebelumnya.

Terima kasih banyak atas waktu Anda. Saya masih belajar Docker.

@jmcejuela Anda tidak akan menggabungkan _images_, Anda akan menjalankannya sebagai wadah terpisah, dan meminta mereka bekerja sama untuk membentuk aplikasi. Anda dapat melakukannya menggunakan Docker Compose, yang memungkinkan Anda untuk menentukan "tumpukan" Anda. Misalnya, lihat https://github.com/docker/example-voting-app/blob/master/docker-compose.yml (dan README; https://github.com/docker/example-voting-app/ gumpalan/master/README.md)

Untuk bagian "ssh", itu sangat tergantung untuk apa Anda ingin menggunakannya; secara keseluruhan, container dianggap "tidak dapat diubah", jadi Anda tidak akan ssh menjadi container dan memodifikasinya, tetapi memutar container baru untuk menggantikan yang lama; data yang perlu bertahan di luar siklus hidup container kemudian disimpan dalam volume, sehingga container baru dapat menggunakan file tersebut.

@jmcejuela Docker builder menerima konten Dockerfile di STDIN, jadi seseorang dapat "relatif" dengan mudah membuatnya? Jika suatu konteks harus diteruskan, maka semuanya harus ditar dan dimasukkan ke docker build . Menurut pengalaman saya, ini adalah cara termudah untuk mendapatkan komposisi.

Saya sedang mengembangkan (dan bermain dengan) sebuah pendekatan, yang dibangun dari konsep di atas. Aplikasi nodejs menyiapkan file TAR di memori (dengan Dockerfile dan file tambahan) dan membuangnya ke STDOUT. STDOUT disalurkan ke docker build . Bagian yang dapat dikomposisi diversi, diuji, dan dirilis sebagai modul NPM. Saya memberikan contoh yang sangat singkat, yang menunjukkan gambar pengujian untuk crond - http://Pastebin.com/UqJYvxUR

Terima kasih @thaJeztah Pada akhirnya saya hanya perlu satu file yang dapat dijalankan oleh rekan pengembang saya untuk memiliki seluruh tumpukan dev, dan kemudian dapat menjalankannya di prod juga jika diperlukan. Saya akan melihat lebih dalam tentang komposisi buruh pelabuhan.

Juga, INCLUDE telah diusulkan sejak lama ( https://github.com/docker/docker/issues/735 ).

@jmcejuela Faktanya adalah bahwa sebagian besar pengguna buruh pelabuhan menginstal dan menggunakan ssh untuk menyiapkan wadah dan memperbaiki masalah dalam wadah yang sedang berjalan. Ini adalah bagaimana buruh pelabuhan sebenarnya digunakan.

Hanya jika Anda salah melakukannya, perintah docker exec telah ada cukup lama sekarang dan saya tidak pernah membutuhkan ssh sejak...

@anentropic Itu hanya berlaku jika Anda menggunakan layanan sederhana tanpa ketergantungan. Jika Anda memiliki rantai ketergantungan yang kompleks untuk layanan apa pun, apa pun yang melibatkan pembelajaran mesin, misalnya, Anda akan menduplikasi kode untuk menerapkan layanan. Dan tidak ada alasan bagus Anda harus melakukan itu. Hanya karena buruh pelabuhan adalah bahasa khusus domain tidak berarti sebagian besar pengetahuan tentang bahasa pemrograman dibuang dan tidak ada pelajaran lama yang berlaku. Kewarasan masih perlu diperhatikan. Menyalin dan menempel resep adalah kegilaan.

Ini juga hanya berlaku jika Anda berlangganan pandangan dunia 'layanan tunggal', yang tidak semua pengguna buruh pelabuhan.

@anentropic Menurut peta jalan Docker, penyediaan wadah yang berjalan melalui docker exec mungkin (datang) sama-sama salah.

PS Mesin rkt telah mencapai v1.0.

@rjurney , :100:

Warisan berganda apakah dicintai atau dibenci adalah fitur yang kompleks dan tidak diragukan lagi akan memiliki perlawanan. Sertakan mengubah Dockerfiles dari resep build menjadi bahasa dengan masalah jalur yang sulit untuk diselesaikan.

Bagaimana jika kita melihat masalah secara berbeda. Bagaimana jika kita dapat " ADD / COPY " memilih file dari gambar buruh pelabuhan lain ke dalam gambar yang sedang dibangun. Dengan cara ini seseorang dapat memperoleh manfaat dari penggunaan kembali fungsionalitas dan menghindari duplikasi kode. Karena kita tidak menggunakan FROM beberapa kali dalam sebuah gambar, tetapi hanya menyalin binari secara eksplisit, ini harus berperilaku dengan cara yang terdefinisi dengan baik dan jika tidak, itu adalah kegagalan. Mengingat bahwa ini berfungsi dengan gambar buruh pelabuhan dan dapat memanfaatkan pendaftar sebagai solusi yang bertentangan dengan beberapa jalur pencarian baru, saya berharap ini adalah proposal yang masuk akal. Bonus tambahannya adalah kita juga tidak perlu menjalankan ulang kode yang sama beberapa kali. Juga, mudah-mudahan, perubahan besar pada pembangun bisa dihindari. Pikiran?

Mungkin ini diusulkan di tempat lain, dalam hal ini tautan akan menyenangkan.

Halo,
Apapun solusi yang dipilih, menyiapkan gambar dari berbagai sumber independen adalah sesuatu yang saya sangat terkejut yang tidak mungkin.
Saya ingin melewatkan persiapan gambar karena pada waktu proses kita dapat melakukan proses ini, sehingga pada waktu proses satu set gambar akan dikerahkan, tidak perlu membuat ulang gambar setiap kali ketergantungan diubah.
Saya mencari alternatif, belum menemukan yang valid, ini adalah celah penggunaan utama.
Terlihat cukup mudah untuk dilakukan menggunakan ACI.
Terima kasih!

:+1: akan menyukai solusi untuk ini dan senang setidaknya dibicarakan. Bahkan jika itu membutuhkan gambar dasar yang sama.

Ternyata menyalin dari gambar lain diusulkan di tempat lain. Ini masalahnya ( https://github.com/docker/docker/issues/18596 ).

terima kasih @jakirkham ..

+1 untuk fungsi pewarisan ganda buruh pelabuhan

EDIT:

Lihat juga: https://github.com/docker/docker/issues/13026

Saya pikir masalah yang Anda hadapi adalah ketidakmampuan untuk membuat resep tidak masuk akal. Penulisan Docker sangat bagus untuk menggunakan banyak wadah dalam suatu aplikasi. Kawanan Docker sangat bagus untuk melakukan hal yang sama dengan banyak node. Tetapi tidak ada cara untuk memasukkan karya orang lain pada tingkat kode sumber, dalam banyak kasus. Anda harus mewarisi sekali atau membuatnya kembali, yang membatasi.

Pada Jum, 18 Mar 2016 jam 09:01, Alvin Chevolleaux < [email protected]

menulis:

Balasan dari @thaJeztah https://github.com/thaJeztah sangat
mencerahkan. Saya baru mengenal Docker dan tidak mengerti mengapa Anda tidak dapat menggabungkan
beberapa _images_ bersama-sama tetapi Docker Compose tampaknya menjadi solusi untuk
menggabungkan beberapa _containers_ menjadi satu aplikasi yang saya cari
untuk.

Saya pikir masalahnya bagi saya adalah saya pikir saya mengerti Docker pada awalnya
tapi sekarang saya menemukan bahwa saya tidak. Saya akan kembali dan melakukan lebih banyak lagi
membaca!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3378#issuecomment -198426036

Russell Jurney twitter.com/rjurney russell. [email protected] relato.io

@rjurney Ya setelah melihat Docker Compose sedikit lagi, Anda benar, itulah kebingungan saya. Misalnya ada gambar PHP dan Gambar Centos tetapi tidak ada pewarisan antara gambar yang berbeda jadi itu semua atau tidak sama sekali. Dalam gambar PHP resmi itu menggunakan debian:jessie tetapi saya ingin pengaturan saya berbasis Centos, jadi sepertinya jika saya ingin menggunakan gambar tertentu saya harus menerima sisa pengaturan atau salin dan tempel sumber Dockerfile dan menggulung gambar saya sendiri dari awal, sepertinya tidak ada jalan tengah di mana saya dapat mencampur dan mencocokkan gambar.

EDIT:
Hanya untuk memperjelas, saya mengerti mengapa Anda tidak dapat menggabungkan gambar berbasis Ubuntu dan Centos bersama-sama, tetapi saya tidak mengerti mengapa Anda tidak dapat memiliki semacam struktur hierarkis. Kemudian alih-alih mengunduh seluruh gambar, Anda hanya mengunduh perubahan dari satu gambar ke gambar lainnya.

INCLUDE akan sangat berguna bagi saya juga. Tanpa itu, saya tinggal copy-paste.

@RomanSaveljev saya tidak mengerti:

Menurut peta jalan Docker, penyediaan wadah yang berjalan melalui docker exec mungkin (datang) sama-sama salah.

Itu tidak mengatakan bahwa docker exec akan ditinggalkan. docker exec selalu menjadi alat debugging, dan begitu juga SSH dalam wadah Docker.

Saya merasa bodoh untuk berpartisipasi dalam ini, tapi apa-apaan ... Saya akan menyarankan ini lagi:

Mengapa kita tidak menyederhanakan masalah dan mulai dengan menerapkan INCLUDE sehingga tidak mengizinkan pewarisan? Dengan kata lain, Anda hanya dapat menyertakan file yang tidak memiliki FROM.

Itu akan menangani banyak kasus penggunaan, dan dorongan akan ada pada file orang TERMASUK untuk bekerja pada sistem operasi apa pun yang masuk akal. uname ada karena suatu alasan. Ini akan menjadi langkah pertama, dan umpan balik tentang implementasi ini akan membantu menentukan lebih jauh.

Itu sepertinya keputusan yang mudah untuk dibuat. Ini tidak akan menjadi satu ton pekerjaan. Ini tidak akan rumit. Benar?

@rjurney pada dasarnya itulah yang dilakukan https://github.com/docker/docker/pull/12749

@rjurney : Jangan merasa bodoh. Meskipun INCLUDE tidak sepenuhnya mencakup permintaan awal, ini adalah langkah ke arah yang benar. Ada beberapa masalah yang dikemas.

1. Bagaimana cara menggabungkan beberapa karya mandiri?
2. Bagaimana cara menyimpan kompilasi seperti itu secara efisien?
3. Bagaimana cara menggabungkan beberapa pekerjaan di level biner, bukan level build?

Mungkin ada lebih banyak item yang dapat ditambahkan ke daftar ini. Solusi INCLUDE menangani poin-poin pertama. Setelah itu ada, itu meletakkan kerangka kerja standar di mana efisiensi penyimpanan biner dapat ditingkatkan secara transparan ke pengguna akhir. Setelah itu ada, maka masuk akal untuk berbicara tentang alat yang melakukan manipulasi yang sama pada file gambar secara langsung. Namun, langkah terakhir ini tentu saja sangat dipertanyakan. Segera setelah Anda melakukannya langsung pada file gambar, ada potensi besar untuk berakhir dengan gambar yang rusak. Namun, jika diasumsikan hanya pengguna yang kuat (mereka yang tahu persis apa yang mereka lakukan) yang akan melakukan opsi ketiga, itu bagi saya sepertinya bukan tambahan yang tidak masuk akal ... akhirnya.

Bagi mereka yang menginginkan sesuatu yang benar-benar dapat dikomposisi dengan cara ini, Anda dapat melihat Nix (NixOS, distribusi Linux dan sistem manajemen paket). Itu hanya mengharuskan Anda untuk mengemas ulang semua perangkat lunak Anda, biasanya membangun dari sumber, dan meninggalkan semua yang Anda pikir Anda ketahui tentang Linux ;). Ini adalah sistem yang bagus, tetapi membutuhkan banyak pekerjaan mengingat tidak banyak orang yang menggunakannya, tetapi saya sangat berharap bahwa ini akan berhasil.

Seperti yang dikatakan orang lain, komposisi Docker lebih tentang menulis di tingkat layanan.

:+1: defo layak untuk dipikirkan tentang model yang dapat dikomposisi - akan sangat brilian jika Anda dapat mengimpor perilaku ke dalam file docker. misalnya saya memiliki kasus penggunaan sekarang di mana saya ingin memasukkan penghematan Apache di sejumlah wadah build yang sangat berbeda berdasarkan linux Alpine - beberapa akan membangun layanan Java, yang lain PHP dan Node.js lainnya.

Akan lebih baik untuk dapat menyertakan instalasi hemat daripada menyalin dan menempel - saya kira saya dapat dengan mudah mengekstrak ke skrip Shell dan TAMBAHKAN dan JALANKAN.

Jadi bagaimana cara menggunakan gambar Ruby-2.3 dan Java-8? Mereka menggunakan gambar debian jessie yang sama dengan dasarnya (saya membaca file docker). Saya hanya ingin menjalankan perintah yang ada di keduanya. Seperti berdiri saya harus menyalin/menempel Java Dockerfile ke dalam Ruby Dockerfile. Aplikasi ini membutuhkan keduanya, sama sekali tidak mungkin saya menyiasatinya.

Saya memang mengambil kesempatan untuk menghapus beberapa perintah Dockerfile saat saya menempelkannya - mereka tidak berbahaya, tetapi hanya berlebihan, karena Dockerfile "dasar" (yang saya tempelkan perintah ke dalamnya) sudah melakukan langkah-langkah itu. Dengan demikian saya dapat melihat argumen bahwa saya tidak benar-benar menginginkan gambar "ruby" & "java", saya sebenarnya sedang membangun gambar "ruby+java all-in-one" ke-3.

Namun, dalam kasus khusus ini, perintah dalam dua gambar tersebut tampaknya sepenuhnya kompatibel - jika saya hanya menggabungkannya, mereka akan berfungsi. Akan berguna untuk dapat menentukan keadaan seperti itu. Saya bukan penggemar berat pendekatan salin/tempel - dalam kasus saya Java dan Ruby Dockerfiles cukup sederhana, tetapi beberapa Dockerfiles jauh lebih kompleks.

Namun, untuk semua orang seperti saya yang menginginkan fitur ini - saya dapat melihat banyak situasi di mana ini akan menjadi masalah. Jadi ini bukan hanya soal menyediakan kemampuan untuk menjalankan "nginx" dan kemudian "ssh" pada gambar buruh pelabuhan yang sama - fungsi yang sama juga memungkinkan Anda menjalankan "debian" dan "centos", yang pasti tidak akan menghasilkan gambar yang bisa diterapkan. Jika pernah diperkenalkan sepertinya itu harus menjadi opsi eksperimental, mati secara default, yang memiliki banyak peringatan yang menyertainya.

Jadi apa pun antarmuka untuk fitur ini, itu harus membuatnya sangat jelas bahwa tanggung jawab untuk mendapatkan perilaku yang dapat digunakan kembali (kumpulan perintah) dengan benar ada pada pengembang Dockerfile.

EDIT: Ah, saya melewatkan diskusi TERMASUK.

Mengapa kita tidak menyederhanakan masalah dan mulai dengan menerapkan INCLUDE sehingga tidak mengizinkan pewarisan? Dengan kata lain, Anda hanya dapat menyertakan file yang tidak memiliki FROM.

Itu akan menangani banyak kasus penggunaan, dan dorongan akan ada pada file orang TERMASUK untuk bekerja pada sistem operasi apa pun yang masuk akal. uname ada karena suatu alasan. Ini akan menjadi langkah pertama, dan umpan balik tentang implementasi ini akan membantu menentukan lebih jauh.

Itu sepertinya keputusan yang mudah untuk dibuat. Ini tidak akan menjadi satu ton pekerjaan. Ini tidak akan rumit. Benar?

:+1:

@rjurney pada dasarnya itulah yang dilakukan #12749

:+1: sempurna, menantikan untuk melihat apa yang akan dapat dilakukan dalam bentuk akhirnya.

Sangat tertarik dengan konsep ini juga. Mekanisme "TERMASUKKAN" adalah solusi yang sangat kasar, tetapi sejujurnya akan mewakili langkah maju yang cukup besar dalam pemeliharaan satu set file buruh pelabuhan.

Secara pribadi saya tidak ingin itu _fail_ ketika menemukan FROM , saya ingin itu _mengabaikan_ FROM dan hanya menerapkan sisa perintah secara berurutan.

Bahwa ini belum terjadi tanpa dukungan FROM adalah sumber terbuka
parodi.

Pada Kam, 19 Jan 2017 jam 10:19, Ken Williams [email protected]
menulis:

Sangat tertarik dengan konsep ini juga. Mekanisme "TERMASUKKAN" adalah mekanisme yang sangat
solusi kasar, tapi jujur ​​akan mewakili langkah maju yang cukup besar dalam
pemeliharaan dari satu set file buruh pelabuhan.

Secara pribadi saya tidak ingin itu gagal ketika bertemu FROM, saya akan
ingin mengabaikan FROM dan hanya menerapkan sisa perintah di
urutan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/3378#issuecomment-273854850 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AACkpS8-EQ7r0BHid75rxeBDhOUDFRXlks5rT6kXgaJpZM4BWkJ9
.

--
Russell Jurney twitter.com/rjurney russell. [email protected] relato.io

Begini masalahnya, saya tidak perlu menggabungkan. Saya pikir banyak masalah dapat diselesaikan dengan rebase. Kasus penggunaan normal saya adalah

A (ubuntu) -> B (mis. nginx)
A (ubuntu) -> C (mis. simpul)

Dan saya ingin gambar B & C gabungan. Biasanya mereka tidak ada hubungannya satu sama lain, jadi itu akan cukup untuk mengubah dasar semua perbedaan antara A dan C ke B. yaitu

A -> B -> C'

Itu sepertinya masalah yang lebih sederhana untuk dipecahkan.

@cloutiertyler Biasanya aplikasi Node.js tidak memerlukan fitur ini untuk bekerja dengan Nginx (menurut saya). Cara Docker akan menjadi dua wadah, satu untuk Nginx, yang lain untuk Node.js. Kami mengonfigurasi wadah Node untuk mengekspos portnya hanya ke wadah Nginx, dan membiarkan wadah Nginx mendengarkan port publik (seperti 80). Adakah alasan mengapa Nginx harus berada dalam wadah yang sama dengan Node?

Contoh file Docker Compose mungkin

version: "2.1"

services:
  app: # Node.js application image
    build: .
  nginx: # Nginx container who can make request to app container
    image: nginx:1.10-alpine
    depends_on:
      - app
    ports:
      - "${PORT:-8080}:80" # public port, you may want PORT=80

@franklinyu saya menghargai jawabannya. Saya sebenarnya hanya menggunakan dua layanan acak sebagai contoh. Kasus penggunaan saya yang biasa akan dimulai dengan layanan generik (mis. node yang berbasis di ubuntu) dan gambar kustom saya sendiri (juga berbasis di ubuntu) dan ingin menggabungkannya.

btw, ini bukan rebasing tetapi membuka banyak kasus penggunaan untuk Dockerfiles.
Dockerfile sekarang mendukung pembangunan multi-tahap. Contoh:

FROM golang AS myapp
COPY . /myapp
RUN cd /myapp && go build

FROM scratch
COPY --from=myapp /myapp /usr/bin/myapp

Anda dapat memiliki tahap sebanyak yang Anda suka.
Parameter --from pada dasarnya mengalihkan konteks ke nama target build yang ditentukan.
Saat Anda docker build -t myapp . , gambar yang dihasilkan bernama myapp:latest akan berasal dari tahap terakhir.
Anda juga dapat membangun tahapan tertentu dengan docker build --target=myapp , misalnya.

Ada beberapa peningkatan Dockerfile lain yang sangat bagus di 17.05 (saat ini tersedia sebagai RC1), cobalah!

Sekarang itu menarik! Aku tidak tahu kamu bisa melakukan itu. Saya harus mencobanya untuk melihat apakah itu menyelesaikan kasus penggunaan umum saya.

Meskipun ini adalah fitur yang hebat, setelah mencobanya, itu tidak benar-benar menyelesaikan masalah saya yang paling umum. Aku baru saja menabraknya lagi hari ini.

Saya ingin gambar Jenkins yang telah menginstal Docker sehingga saya dapat membangun dari dalam wadah. Faktanya adalah tidak ada cara untuk melakukan ini tanpa mereplikasi proses instalasi satu atau yang lain di Dockerfile saya.

Ini adalah kasus di mana argumen yang ditutup-tutupi tentang ini tidak diperlukan karena setiap wadah seharusnya hanya satu layanan jelas tidak berlaku. "Satu layanan" saya menggabungkan fungsionalitas Docker dan Jenkins.

Faktanya adalah tidak ada cara untuk melakukan ini tanpa mereplikasi proses instalasi satu atau yang lain di Dockerfile saya.

Jadi Anda ingin menghancurkan dua file docker menjadi satu sehingga Anda tidak perlu menyalin/menempelkan barang?

Salin/tempel sama dengan forking dalam kasus ini. Apa yang ingin saya lakukan adalah menghindari forking Dockerfile jadi saya tidak melewatkan perbaikan bug/keamanan atau perubahan lain ketika itu selalu berubah nanti.

Tidak bisa lewat begitu saja. Mencari cara untuk mendistribusikan perubahan melalui rantai panjang pewarisan gambar (lebih dalam dari 2). Multi-tahap sepertinya bukan hal yang memperjelas masalah. Memiliki entitas yang hanya berisi blok arahan, memungkinkan saya untuk memasukkannya ke dalam semua gambar pewaris saya, bersama dengan fungsionalitas gambar dasar terlihat seperti evolusi rasional.

Bagi mereka yang bertanya-tanya cara yang tepat untuk melakukan ini, dari perspektif Docker, luangkan beberapa menit untuk meninjau:
https://github.com/floydhub/dockerfiles

Di sini dia membuat seluruh pohon Dockerfiles. Saat Anda menuruni pohon, Anda menemukan kombinasi ketergantungan yang berbeda, masing-masing DARI tingkat di atas dalam pohon. Jadi jika Anda mengikuti pohon dari
-ubuntu->common-deps->python3->deepLearningBase->pyTorch
dan kamu benar-benar menginginkannya

-ubuntu->common-deps->python3->deepLearningBase->pyTorch 
+
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow 

Yang akan Anda lakukan hanyalah menambahkan simpul (folder) di bawah deepLearningBase untuk keduanya, mis
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow-pyTorch

Sekarang, Anda masih harus membuat file docker yang menggabungkan file docker pyTorch dan TensorFlow, tetapi
kuncinya adalah file-file itu akan SANGAT SEDERHANA, hanya beberapa baris instalasi di atas deepLearningBase.

Jadi yang benar-benar dibutuhkan adalah untuk beberapa repositori github skala besar seperti ini, untuk "dunia" yang berbeda, seperti Pengembangan Web, Pembelajaran Mendalam, Perangkat lunak yang disematkan, dll.

Kemudian Anda cukup mengikuti pohon ke bangunan yang Anda butuhkan, dan jika belum ada orang lain yang membuatnya, tambahkan saja sebuah simpul dan gabungkan 2 atau 3 baris apt-get dan buat lingkungan baru Anda.

Itu terlihat seperti gaya komposisi "pilih-petualangan-Anda-sendiri". TERMASUK akan jauh lebih sederhana. Sial, saya hanya ingin membuat gambar gcc dengan nano jadi saya tidak perlu menginstal nano dari apt-get setiap saat!

Saya setuju dengan @chambm dalam komentarnya di atas. Tidak ada alasan mengapa hal ini tidak mungkin dilakukan dalam banyak kasus (konflik seharusnya cukup jarang, karena terjadi pada OS yang dikelola secara manual).

Ini adalah kasus penggunaan yang sangat mirip dengan yang dikomentari @cloutiertyler , di mana tidak ada solusi @franklinyu , tidak ada build multi-tahap yang dikomentari oleh @cpuguy83 yang berlaku:

• A (debian:stretch-slim)
  
  
  
  • dockerfileAB -> B (python:slim-stretch)
  
  
  • dockerfileAC -> D ([build-stage] python-slim)
    
    
    
    
    
    • dockerfileDE -> E (ghdl/ext:vunit)
    
    
    
  
  
  • dockerfileAC -> C (ghdl/run:stretch-mcode)
  
  

di mana:

• Langkah-langkah dari A ke C persis sama dengan langkah-langkah dari B ke D (dockerfileAC).
• Tim pengembangan B tidak tahu apa-apa tentang C, D atau E.
• Tim pengembangan C tidak tahu apa-apa tentang B, D atau E.

Pengguna yang ingin membangun D (dan/atau E), harus memiliki akses ke dockerfileAC, tetapi tidak perlu mengetahui tentang dockerfileAB. Oleh karena itu, pengguna harus memiliki pemahaman yang lebih baik tentang satu ketergantungan (C) daripada yang lain (B). Idealnya, Anda dapat mengandalkan tim A dan B, dan hanya membangun D sebagai A + (diff(B,A) + diff(C,A)) (gabung) atau A + diff(B,A) + diff(C,A) (rebase).

Karena GHDL bukan layanan web dan VUnit bukan klien web, kedua alat harus dipasang di gambar/wadah (E) yang sama. Build multi-tahap tidak berguna, karena kita perlu membangun dockerfile (mungkin tidak diketahui) dengan dua label FROM , ini bukan rantai maju tunggal.

Jika menemukan kasus penggunaan ini mirip dengan penggabungan/rebase dua cabang git: terkadang tidak ada konflik, terkadang konflik dapat diselesaikan dengan mudah, terkadang tidak dapat digabungkan sama sekali karena tidak ada riwayat umum... Apakah ada alat, baik resmi atau eksternal, yang menyediakan fitur ini? Perhatikan bahwa tidak apa-apa jika alat hanya mengekspor dua gambar ke cabang git dan benar-benar menggunakan git untuk penggabungan.

@1138-4EB Lihat https://github.com/moby/buildkit

Luar biasa ini masih menjadi isu dan topik. Seberapa sulit untuk "TERMASUKKAN beberapa gambar", lalu ketika menguraikannya, periksa basisnya kompatibel (dalam rantai FROM) dan jika demikian, jalankan sisa file ITU pada saat itu (seolah-olah saya telah menyalin Dockerfile dari proyek dan menempelkannya ke milikku)?

Seluruh alasan "orang akan melakukan hal-hal buruk yang tidak mereka sadari" tidak masuk akal dalam konteks ini. Ini sudah sangat rumit dan itulah mengapa kami membutuhkan ini untuk membantu menyederhanakannya.

@rainabba Ini adalah komentar yang sama sekali tidak membantu.
Pada dasarnya ada dua alasan mengapa itu tidak dilakukan, baik:

1. Ini tidak begitu mudah
2. Tidak ada yang meluangkan waktu untuk melakukan pekerjaan itu.

Pada kenyataannya, biasanya keduanya.

1. Ini adalah masalah penguraian dan penggantian string yang dapat diselesaikan oleh pembuat kode baru dalam 10 menit JIKA mereka tahu di mana dalam kode. Saya tidak mengatakan itu akan dapat digunakan dalam semua kasus, tetapi untuk kasus-kasus terbatas yang saya lihat disarankan di sini berulang-ulang (di mana pangkalan secara efektif umum), itu adalah dering mati.

2. Tentu saja tidak, utas ini memberikan ~102 alasan mengapa hal itu tidak dapat atau tidak boleh dilakukan, jadi mengapa ada orang yang berpikir untuk melakukannya?

Di sisi lain, komentar saya berfungsi (seperti BEGITU banyak orang lain di sini) untuk menunjukkan bahwa ada kebutuhan dan dengan harapan untuk mempengaruhi sikap yang menghalangi atau setidaknya bertindak sebagai pengingat. Jika itu "sama sekali tidak membantu", maka Anda baru saja menjelaskan mengapa masalah ini (permintaan fitur yang diabaikan) masih ada dan aktif dan ini bukan masalah teknis.

Ini jauh lebih dari sekadar mengurai string.
Docker dan Dockerfile digunakan oleh jutaan orang. Menambahkan API adalah hal yang signifikan ... bahkan di luar itu implementasi yang mendasarinya bukanlah "mengurai string".

Bagaimanapun, ada banyak proposal untuk memecahkan masalah dan ini adalah masalah yang sangat lama dan tertutup.

Saya pikir jika Docker tidak menemukan solusi bersih untuk skenario ini, itu mungkin akan digantikan oleh alat apa pun yang menemukannya.

Saya melihat salah satu rekan saya menggunakan pola berikut, yang mungkin merupakan solusi yang layak:

ARG from
FROM $from
... rest of dockerfile

Saya belum mencobanya sendiri, jadi saya tidak yakin bagaimana cara kerjanya dalam praktik, misalnya bagaimana perilakunya dengan caching, dll.

Memang, ini adalah masalah yang sangat penting, dan belum ditangani dengan baik. Saya kagum perusahaan sebesar Docker belum menanganinya.

Hanya dua sen saya ... Saya baru belajar lebih banyak tentang Docker saat ini dan saya merasa sesuatu seperti INCLUDE akan sangat berguna. Saya menyukai contoh pewarisan berganda di atas dan ingin menanggapi komentar tentang kemungkinan masalah dan konflik dengannya.

Warisan berganda sulit dilakukan dalam bahasa apa pun yang mendukungnya, tetapi ketika konflik terjadi, pembuat file Docker bertanggung jawab untuk memikirkan kembali apa yang mereka lakukan dan memulai lagi. Docker seharusnya hanya membuat gambar dan tidak mencoba membuktikan bahwa build tidak memiliki masalah.

@kosminonea

Saya merasa sesuatu seperti INCLUDE akan sangat berguna

Saya memiliki dukungan untuk makro di https://github.com/larytet/dockerfile-generator/ Saya dapat mendukung "sertakan" juga.

Itu akan kehilangan intinya. Tujuannya bukan untuk memasukkan Dockerfile
definisi. Tujuannya adalah untuk memasukkan gambar buruh pelabuhan. Ini akan
tampak tidak masuk akal karena tidak masuk akal:

dari fedora
termasuk ubuntu / ubuntu
termasuk debian /debian

Secara wajar saya berharap ini dimulai dengan citra fedora.
Kemudian tambahkan gambar untuk ubuntu di bawah folder /ubuntu. Kemudian ditambahkan
gambar untuk debian di bawah /debian .

Ini tentu saja tidak masuk akal, mengapa saya ingin mencampur banyak operasi
sistem menjadi satu gambar? Tetapi contoh yang lebih berguna mungkin:

dari fedora
termasuk plex / plex
termasuk commericalremover /plex/add-on/commericalremover

Sekarang dalam hal ini lebih masuk akal. Dalam hal ini jika ini adalah gambar lain
tidak memiliki komponen khusus yang beroperasi, saya memiliki cara mudah untuk membuat sesuatu
modular.

Pada Rabu, 8 Agustus 2018 pukul 15:48, Arkady Miasnikov [email protected]
menulis:

Saya merasakan sesuatu seperti TERMASUK
Saya memiliki dukungan untuk makro di
https://github.com/larytet/dockerfile-generator/ Saya dapat menambahkan "sertakan"
mendukung juga.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/3378#issuecomment-411529506 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ADBcWAtBDEp_LXpW3HUkHd3Pw5IVAXvqks5uO0ChgaJpZM4BWkJ9
.

Yang terakhir itu mungkin sudah; COPY --from menerima tahap pembuatan, atau gambar, jadi misalnya;

FROM busybox

COPY --from=alpine:latest / /
COPY --from=docker:latest /usr/local/bin/docker /usr/local/bin/

Sunting; atau untuk mengambil contoh yang sebenarnya;

FROM fedora

COPY --from=ubuntu:latest / /ubuntu/
COPY --from=debian:latest / /debian/

Tepat. Itulah sebabnya saya akan mempertimbangkan pembaruan 2017 yang menambahkan "COPY
--from" karena telah menyelesaikan permintaan awal. Benar-benar ada
tidak ada lagi yang saya cari dari tiket ini.

Ide-ide yang muncul kemudian seperti auto-rebasing termasuk, akan
fitur bagus. Tapi mereka melampaui permintaan aslinya.

Salam,

Tagihan

Pada Kamis, 9 Agustus 2018 pukul 12:55, Sebastiaan van Stijn [email protected]
menulis:

Yang terakhir itu mungkin sudah; SALIN --dari menerima keduanya a
membangun-tahap, atau gambar, jadi misalnya;

DARI busybox

SALIN --dari= alpine:terbaru / /
SALIN --dari= buruh pelabuhan: /usr/local/bin/docker terbaru /usr/local/bin/

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/3378#issuecomment-411824851 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ADBcWPE738cs9xf3ZHSOaUd1foI1XVIQks5uPGmYgaJpZM4BWkJ9
.

@thaJeztah Menggunakan

Tentu saja, menggabungkan gambar Docker bukanlah hal yang sepele. Karena skrip arbitrer dapat dijalankan selama build, proses build menolak segala upaya umum untuk mendeteksi konflik otomatis; masalah penghentian mengatakan hai! Yang terbaik yang dapat Anda lakukan (singkat secara signifikan membatasi apa yang dapat dilakukan build) adalah mendefinisikan semantik yang tepat: katakan FROM / INCLUDE menang (misalnya jika mereka "menulis" file yang sama) atau gagal pada konflik tingkat sistem file atau ....

Masalah yang kadang-kadang dinyatakan dari gambar "dasar" yang berbeda (stretch vs ubuntu vs alpine vs ...), namun, _is_ sederhana: mengharuskan DAG dari dependensi gambar tidak hanya memiliki satu sumber (gambar saat ini) tetapi juga satu wastafel ("nenek moyang" bersama dari semua gambar dalam "hierarki").

Pada akhirnya, tentu saja, Anda akan mendapatkan sampah-masuk-sampah-keluar -- apakah ini pernah berbeda, benarkah?

FWIW, kasus penggunaan saya adalah:

1. Menjalankan aplikasi web Tomcat dengan database PostgreSQL dan penyimpanan objek S3.
   Meskipun ini dapat diselesaikan dengan menggunakan Docker Compose, satu wadah mungkin lebih baik.
2. Pembuatan multi-bahasa berjalan dalam wadah Docker (mis. di Jenkins, Circle CI, ...).
   Ada gambar resmi untuk rantai alat paling populer, tetapi mendapatkan satu wadah yang dilengkapi untuk menangani lebih dari satu proses persis seperti yang dibahas di sini.

@reitzig , jika Anda memerlukan pembuatan Dockerfiles yang dinamis, saya sarankan menambahkan bahasa khusus domain. Ada beberapa contoh yang saya ketahui

• https://github.com/avirshup/DockerMake
• http://docteurklein.github.io/2015/01/11/docker-auto-builds-and-me/
• https://blog.dockbit.com/templating-your-dockerfile-like-a-boss-2a84a67d28e9
• https://github.com/larytet/dockerfile-generator/

@reitzig Ini bukan satu-satunya pilihan. Opsi yang tepat adalah membatasi TERMASUK untuk menghindari masalah besar. TERMASUK tidak dapat mewarisi. Itu ada. Sederhana. Masih sangat berguna.

Permintaan fitur ini populer tetapi Docker Gratis seperti dalam Bir tetapi tidak dengan cara apa pun Gratis seperti dalam Kebebasan.

@rjurney Dengan dimasukkannya dukungan buildkit sejak 18.06, pengguna dapat menyediakan parser frontend mereka sendiri untuk builder. Sudah ada parser Dockerfile eksperimental resmi (dari Docker Inc) yang menyertakan banyak fitur baru (dukungan untuk rahasia sebagai permulaan).

Anda tentu saja juga dapat menambahkan perilaku "TERMASUKKAN" Anda sendiri di frontend Dockerfile khusus, atau Anda dapat melakukan sesuatu yang sama sekali berbeda yang sama sekali bukan Dockerfile (ada contoh untuk buidpacks).

Untuk menggunakan frontend khusus, cukup arahkan Docker ke gambar yang dapat menanganinya. Lakukan ini sebagai komentar pada baris pertama Dockerfile Anda (atau apa pun itu) syntax = myCustomFrontendImage

Lebih detail di sini:
https://docs.docker.com/develop/develop-images/build_enhancements/#overriding -default-frontends

Dengan buildkit diaktifkan, Docker dapat membangun apa pun yang Anda inginkan (bahkan tidak harus dalam format Dockerfile) dengan fitur apa pun yang Anda butuhkan.

Permintaan fitur ini populer tetapi Docker Gratis seperti dalam Bir tetapi tidak dengan cara apa pun Gratis seperti dalam Kebebasan.

Terlepas dari topik itu, saya pikir perlu dicatat bahwa Anda salah. Berkat lisensi Apache Docker, setiap orang memiliki kebebasan untuk melakukan fork dan mengembangkan penerjemah mereka sendiri untuk Dockerfiles yang menyediakan fitur yang dikembangkan di sini. Jika mereka berhati-hati, gambar yang dihasilkan akan kompatibel dengan runtime/alat Docker yang ada.
Tentu saja, pengelola proyek Docker juga bebas untuk tidak menggabungkan fitur seperti itu ke dalam fork mereka (asli?).

@reitzig Itu jelas hanya kata-kata kasar yang tidak berarti tanpa benar-benar merujuk apa itu perangkat lunak bebas. Moby adalah perangkat lunak gratis tentunya.

Saya tidak tahu itu sekarang berlisensi Apache. Saya minta maaf atas komentarnya dan
pikir ini hebat!

Russell Jurney @rjurney http://twitter.com/rjurney
russell. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

Pada Wed, Jan 16, 2019 at 04:17 Raphael R. [email protected] menulis:

Permintaan fitur ini populer tetapi Docker Gratis seperti dalam Bir tetapi tidak oleh
cara apapun Gratis seperti dalam Kebebasan.

Terlepas dari topik itu, saya pikir perlu dicatat bahwa Anda adalah
salah. Berkat lisensi Apache Docker, setiap orang memiliki kebebasan untuk
garpu dan kembangkan penerjemah mereka sendiri untuk Dockerfiles yang menyediakan
fitur yang dikembangkan di sini. Jika mereka berhati-hati, gambar yang dihasilkan akan
kompatibel dengan runtime/alat Docker yang ada.
Tentu saja, pengelola proyek Docker juga bebas untuk tidak
menggabungkan fitur seperti itu ke dalam garpu mereka (asli?).

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/3378#issuecomment-454758482 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AACkpdj_YO76ge79bm4G8FBmhOdbjhO9ks5vDxhvgaJpZM4BWkJ9
.

Maaf, saya tidak tidur nyenyak dan saya membuat kesalahan. Komentar saya berdiri.
Gratis seperti dalam Beer berarti Apache. Bebas seperti dalam Kebebasan berarti kontrol komunitas.
Proyek Apache atau bentuk pemerintahan lainnya.

Russell Jurney @rjurney http://twitter.com/rjurney
russell. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

Pada Rab, Jan 16, 2019 at 12:32 PM Russell Jurney [email protected]
menulis:

Saya tidak tahu itu sekarang berlisensi Apache. Saya minta maaf atas komentarnya dan
pikir ini hebat!

Russell Jurney @rjurney http://twitter.com/rjurney
russell. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

Pada Wed, Jan 16, 2019 at 04:17 Raphael R. [email protected]
menulis:

Permintaan fitur ini populer tetapi Docker Gratis seperti dalam Bir tetapi tidak oleh
cara apapun Gratis seperti dalam Kebebasan.

Terlepas dari topik itu, saya pikir perlu dicatat bahwa Anda adalah
salah. Berkat lisensi Apache Docker, setiap orang memiliki kebebasan untuk
garpu dan kembangkan penerjemah mereka sendiri untuk Dockerfiles yang menyediakan
fitur yang dikembangkan di sini. Jika mereka berhati-hati, gambar yang dihasilkan akan
kompatibel dengan runtime/alat Docker yang ada.
Tentu saja, pengelola proyek Docker juga bebas untuk
tidak menggabungkan fitur tersebut ke dalam garpu mereka (asli?).

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/3378#issuecomment-454758482 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AACkpdj_YO76ge79bm4G8FBmhOdbjhO9ks5vDxhvgaJpZM4BWkJ9
.

Gratis seperti dalam Beer berarti Apache.

Tidak setuju. Freeware dapat berupa perangkat lunak berpemilik.

Bebas seperti dalam Kebebasan berarti kontrol komunitas.

Apa itu kontrol komunitas? Proyek dijalankan oleh yayasan? Jadi Anda akan mempertimbangkan VS Code, Atom editor, dan Ubuntu sebagai perangkat lunak tidak bebas? Maka definisi Anda sangat berbeda dari yang diusulkan oleh FSF, EFF, dan banyak organisasi lainnya.

Saya setuju bahwa Docker Inc tidak secara aktif berdiskusi dengan komunitas dalam masalah ini, tetapi ini tidak ada hubungannya dengan "Bebas seperti dalam Kebebasan".

Maaf teman-teman, jangan lakukan diskusi semacam ini di pelacak masalah.

Saya setuju bahwa Docker Inc tidak secara aktif berdiskusi dengan komunitas dalam masalah ini

Kami telah memungkinkan untuk mendukung format build apa pun yang Anda inginkan melalui docker build . Format Dockerfile "resmi" tidak mendukung opsi ini, tetapi itu tidak berarti bahwa docker build tidak dapat menggunakannya.
Lihat https://matt-rickard.com/building-a-new-dockerfile-frontend/ sebagai contoh membangun frontend khusus yang berfungsi dengan docker build .
Perhatikan bahwa frontend ini adalah contoh bagaimana Anda dapat melakukan sesuatu yang sama sekali berbeda dari format Dockerfile, tetapi itu tidak perlu. Anda dapat mengambil format Dockerfile yang ada dan menambahkan fungsionalitas Anda sendiri jika Anda mau.

Sejauh menambahkan sesuatu ke dalam format Dockerfile resmi.... Saya akan mengatakan bahwa proposal selalu diterima, formatnya dipertahankan di https://github.com/moby/buildkit.
Namun, ingatlah, setiap fitur baru berarti beban pemeliharaan baru, termasuk sering kali membatasi apa yang dapat dilakukan di masa mendatang.

Saya pikir kemungkinan banyak kasus penggunaan untuk menggabungkan beberapa Dockerfile sebenarnya dapat diselesaikan dengan fungsionalitas baru di Dockerfile... khususnya kemampuan untuk COPY --from dan RUN --mount dari gambar arbitrer.

Jika INCLUDE hipotetis ini hanya dapat membuat wadah tambahan sebagai detail impl dengan saya TIDAK harus memberikan @#$% itu akan sangat mengurangi jumlah frustrasi seputar promosi penjualan implisit dan cerdik dari wadah yang dapat dikomposisi. Saya benar-benar hanya ingin kembali ke aplikasi dan memberikan fungsionalitas. Maaf untuk getarannya yang buruk, tapi saya docker/container noob dan mengalami kebingungan yang sama seperti yang telah diungkapkan banyak poster lain.

Bagaimana jika Anda bisa melakukan ini:

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   custom image (with both python and rust)
             \                                 /
              \----- rust:1.44-alpine3.12 ----/

_Perhatikan bahwa kedua gambar adalah turunan dari gambar yang sama. Ini kuncinya!_

Semudah ini:

FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

_Dibandingkan saat menggunakan instruksi "COPY --from image" (pembuatan multi-tahap), Anda tidak perlu memikirkan detail implementasi (file/variabel lingkungan mana yang akan disalin)._

Seperti apa sekarang jika Anda ingin menggabungkan gambar

FROM alpine:3.12.0

# INCLUDE rust:1.44-alpine3.12
COPY --from=rust:1.44-alpine3.12 / /
ENV RUSTUP_HOME=/usr/local/rustup \
    CARGO_HOME=/usr/local/cargo \
    PATH=/usr/local/cargo/bin:$PATH \
    RUST_VERSION=1.44.1

# INCLUDE python:3.8.3-alpine3.12
COPY --from=python:3.8.3-alpine3.12 / /
ENV PATH /usr/local/bin:$PATH
ENV LANG C.UTF-8
ENV GPG_KEY E3FF2839C048B25C084DEBE9B26995E310250568
ENV PYTHON_VERSION 3.8.3
ENV PYTHON_PIP_VERSION 20.1.1
ENV PYTHON_GET_PIP_URL https://github.com/pypa/get-pip/raw/eff16c878c7fd6b688b9b4c4267695cf1a0bf01b/get-pip.py
ENV PYTHON_GET_PIP_SHA256 b3153ec0cf7b7bbf9556932aa37e4981c35dc2a2c501d70d91d2795aa532be79

_ENV-instruksi di-copy-paste dari Dockerfiles dari gambar-gambar ini._

Ini juga akan memungkinkan penggunaan kembali wadah yang jauh lebih baik, dan membuatnya sangat mudah untuk menyatukan barang-barang yang bisa memakan waktu lama untuk dikompilasi atau dibangun sendiri!

Pertimbangkan bahwa dengan pendekatan ini, sebuah program hanya perlu dikompilasi sekali per platform/versi gambar dasar - dan lebih mudah untuk digunakan kembali, daripada mengimplementasikannya sendiri. Pikirkan saja berapa kali "roda telah diimplementasikan kembali" di C++ karena kurangnya manajer paket yang baik/universal. Apakah kita ingin situasi serupa muncul untuk Docker?

@bergkvist , lihat https://github.com/moby/moby/issues/3378#issuecomment -381449355 dan https://github.com/moby/moby/issues/3378#issuecomment -381641675.

Bagi saya, tidak ada solusi yang Anda usulkan yang sesuai dengan diagram. Sebagai gantinya, Anda melakukan:

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   \
             \                                   \
              \----- rust:1.44-alpine3.12 --------\ custom image 

Jadi, file apa pun yang dimodifikasi di rust ditimpa oleh python . Menggabungkan mereka tanpa menyalin satu dari yang lain akan membutuhkan beberapa penggabungan.

@eine Ya, jika terjadi konflik, file akan ditimpa. Itu benar. Jadi sosok yang simetris akan menjadi kasus khusus ketika tidak ada file (relevan) yang tumpang tindih. Versi gambar Anda lebih umum.

Maksud saya tentang memiliki kedua gambar yang mewarisi dari gambar yang sama persis, adalah bahwa kemungkinan konflik kritis mungkin tipis.

Saya membayangkan bahwa mungkin timbul beberapa konflik terkait dengan file manajer paket. Jika kedua gambar menggunakan manajer paket untuk menginstal hal yang berbeda. Saya tidak yakin apakah ada "konflik umum" lain seperti itu yang dapat ditangani dengan semacam kasus khusus.

Menggabungkan dua file sama sekali tidak mudah. Saya pikir dalam kasus umum, mungkin lebih baik menimpa saja daripada mencoba menjadi pintar. Setidaknya lebih mudah untuk men-debug ketika sesuatu tidak berfungsi.

Sejak saya berkomentar di sini 4 hari yang lalu, saya memutuskan untuk belajar Golang, dan melihat kode frontend untuk kode moby/buildkit.

Saya sekarang telah membuat frontend khusus yang menerima pernyataan INCLUDE seperti yang saya diskusikan di atas.

#syntax=bergkvist/includeimage
FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

Untuk menggunakan sintaks khusus, ingatlah untuk menyetel DOCKER_BUILDKIT=1 saat membuat.

DOCKER_BUILDKIT=1 docker build -t myimage .

Kode tersedia di sini: https://github.com/bergkvist/includeimage
Dan gambar di Docker Hub: https://hub.docker.com/r/bergkvist/includeimage