Saya baru saja melihat ini

Penggunaan: docker build [OPTIONS] PATH | URL | -

jadi jika kamu lari

docker build -t my/thing my-dockerfile

mengeluh tentang file tar yang terlalu pendek.

Tampaknya bagi saya bahwa opsi 'PATH' tidak didokumentasikan, jadi itu mungkin memiliki makna warisan?

Jadi - saya ingin tahu apakah mendeteksi apakah PATH adalah file, dan bukan Tarfile.

secara pribadi, saya memiliki satu set Dockerfiles yang saya gunakan untuk menguji, dan lebih suka memiliki semuanya dalam satu direktori dan juga memiliki konteks penuh.

PATH itu merujuk ke direktori, bukan Dockerfile tertentu.

oh, dan kemudian Tars direktori itu untuk dikirim ke server - keren!

jadi mungkin untuk mendeteksi isafile, Tar up dir-nya, dan kemudian ganti Dockerfile di tarball itu dengan file yang ditentukan.

atau menggunakan -f dengan cara yang sama - memungkinkan definisi Dockerfile Anda hidup terpisah dari payload

sekarang untuk mengetahui cara kerja tes, cobalah dan lihat apakah itu berhasil untuk saya

Itu tidak tar apa pun - PATH adalah direktori yang mengasumsikan ada Dockerfile

tidak hanya itu yang dilakukan dengan PATH itu - membaca kode, 'konteks' dikirim ke server dengan menelusuri direktori.

(ok, jadi saya masih tidak tahu, dan saya baru membaca kode selama beberapa menit terakhir, jadi terimalah dengan sedikit keraguan)

Benar, jadi semua file nonremote yang dirujuk melalui ADD juga harus berada di direktori yang sama atau daemon tidak akan dapat mengaksesnya.

Ah, saya mengerti apa yang Anda katakan - ya - itulah yang saya inginkan - cara untuk menentukan dockerfile dengan -f, dan kemudian PATH direktori yang mungkin terpisah.

jadi saya bisa memiliki:

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

2108 (menambahkan arahan include ke Dockerfiles) menambahkan kerutan yang menarik

harus menyertakan relatif terhadap dockerfile yang ditentukan, atau PATH. belum penting sekalipun.

seru:

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

sebagai bonus tambahan - belum ada tes CmdBuild, jadi coba tebak apa yang harus saya pelajari terlebih dahulu :)

@SvenDowideit apakah Anda mengerjakan ini? Saya berpikir untuk mungkin meretasnya hari ini

Saya perlahan-lahan membiasakan diri dengan kode dan pergi, jadi lakukanlah - saya terlalu bersenang-senang hanya dengan menulis tes unit (mungkin Anda dapat menggunakan komit pengujian untuk membantu :)

saya akan melakukan :)

Saya ingin melihat fungsi ini juga. Kami memiliki sistem yang dapat berjalan dalam 3 mode berbeda dan kami ingin menggunakan 3 kontainer berbeda -- 1 untuk setiap mode. Itu berarti 3 file buruh pelabuhan yang hampir identik hanya dengan CMD yang berbeda. Tetapi karena jalur hanya menjadi direktori, dan direktori menjadi konteks untuk perintah ADD, saya tidak dapat menjalankannya sekarang.

Jadi: +1 dari saya!

Sepertinya ini mungkin memiliki tujuan akhir yang sama dengan #1618 (meskipun dengan pendekatan yang berbeda). Idenya adalah menggunakan satu Dockerfile dengan beberapa instruksi TAG yang menghasilkan banyak gambar, versus beberapa Dockerfile dan sistem penyertaan seperti yang diuraikan di sini. Pikiran?

Sepertinya jika Anda dapat menyalurkan Dockerfile, Anda juga harus dapat menentukan jalur. Tertarik untuk melihat apa yang muncul dari #1618 tetapi saya pikir ini menawarkan lebih banyak kemungkinan.

Di sinilah saya berada: https://github.com/peterbraden/docker/compare/2112-specify-dockerfile?expand=1

Saya terlempar oleh fakta bahwa dokumentasi tidak menyatakan dengan jelas bahwa direktori yang berisi Dockerfile adalah konteks build - saya membuat asumsi yang salah bahwa konteks build adalah direktori kerja saat ini, jadi jika saya meneruskan jalur ke Docerfile sebagai gantinya karena berada di direktori saat ini, file yang saya coba TAMBAHKAN dari direktori kerja saat ini dibom dengan kesalahan "tidak ada file atau direktori".

Saya mendapatkan kesalahan yang sama, Ada Ide

buruh pelabuhan membangun Dockerfile

Mengunggah konteks

2013/12/11 21:52:32 Error: Error build: Tarball terlalu pendek

@bscott coba docker build . sebagai gantinya. Build mengambil direktori, bukan file, dan itulah "konteks build". :)

Bekerja Thx!, Saya hanya ingin memilih di antara file Docker yang berbeda.

+1 dari saya.

Saya perlu membuat banyak gambar dari sumber saya. Setiap citra merupakan perhatian tersendiri yang membutuhkan konteks yang sama untuk dibangun. Mencemari satu Dockerfile (seperti yang disarankan di #1618) adalah miring. Akan jauh lebih bersih bagi saya untuk menyimpan 3 file <image-name>.docker di sumber saya.

Saya ingin melihat sesuatu seperti ini diterapkan.

Ini lebih sulit untuk diterapkan daripada yang terlihat pada awalnya. Tampaknya ./Dockerfile cukup matang. Setelah penyelidikan awal setidaknya file-file ini terlibat:

api/client.go
archive/archive.go
buildfile.go
server.go

client menggunakan archive untuk men-tar build context dan mengirimkannya ke server yang kemudian menggunakan archive untuk meng-untar build context dan serahkan byte ke buildfile .

Implementasi termudah sepertinya melibatkan perubahan client dan archive untuk menimpa ./Dockerfile tar dengan file yang ditentukan melalui opsi ini. Saya akan menyelidiki lebih lanjut.

@thedeeno Saya akan melihat dengan sangat cepat dan menunjukkan kepada Anda apakah perubahan harus dilakukan. Saya pikir itu hanya di satu tempat.

+1 dari saya!

Saya telah mengikuti #1618 dan #2112 dan ini adalah solusi paling elegan.

Ada satu kasus penggunaan khusus dalam pengembangan saya di mana fitur ini akan sangat berguna... Saat bekerja pada aplikasi yang memiliki peran "web" dan "pekerja". Saya ingin membuat dua file buruh pelabuhan untuk situasi ini "Dockerfile-web" dan "Dockerfile-worker". Saya kemudian dapat membangun keduanya, menandainya, dan mendorongnya ke repositori gambar saya. Saya kemudian akan menjalankan beberapa instance front-end web di belakang penyeimbang beban dan banyak pekerja untuk menangani tugas yang didorong ke dalam antrian.

+1 sebagai alternatif #2745.

+1

Saya terkejut menemukan bahwa Dockerfile -hardcode, serta konteks build dipaksa menjadi direktori Dockerfile dan tidak dapat ditimpa bahkan dengan flag baris perintah. Ini sangat membatasi kegunaan dan fleksibilitas Docker sebagai alat pengembangan, pengujian, dan penerapan.

+1
Saya akan menghargai perubahan itu

+1
Sangat membutuhkan ini.

5033 harus mengizinkan fitur ini. cc/@crosbymichael

@shykes apa pendapat Anda tentang perubahan ini? Saya tidak berpikir Anda setuju atau mungkin tahu solusi yang lebih baik untuk memecahkan masalah yang sama.

Aku ragu-ragu.

Di satu sisi, saya tidak ingin membatasi kemampuan orang untuk menyesuaikan bangunan mereka.

Di sisi lain, saya khawatir hal yang sama akan terjadi dengan _run -v /host:/container_ dan _expose 80:80_. Dengan kata lain, itu akan memungkinkan 1% yang tahu apa yang mereka lakukan untuk menambahkan penyesuaian yang keren - dan 99% lainnya kemudian menembak diri mereka sendiri dengan sangat buruk.

Misalnya, kami memiliki banyak pengguna Docker baru yang memulai dengan volume yang dipasang di host alih-alih volume biasa. Dan kami harus menghentikan sintaks _expose 80:80_ sama sekali karena terlalu banyak orang yang menerbitkan gambar yang tidak dapat dijalankan lebih dari sekali per host, tanpa alasan yang jelas.

Jadi pertanyaan saya adalah: bukankah kita mengambil risiko memiliki banyak repositori sumber yang tidak dapat dibangun berulang kali dengan _docker build

@shykes Saya mengalami masalah yang Anda jelaskan _karena_ batasan Dockerfile ini. Berikut adalah beberapa kasus penggunaan:

1. Saya memiliki lingkungan build berbasis Docker yang menghasilkan artefak (file JAR dalam kasus ini). Lingkungan build berbeda dari lingkungan run (dependensi berbeda, gambar lebih besar, dll., jadi saya tidak ingin mewarisi build env ke runtime. Bagi saya paling masuk akal untuk memiliki Dockerfile build dan jalankan runtime env di sekitar JAR. Jadi saya memiliki file Dockerfile.build yang membangun dan menjalankan build env dan membuat JAR. Tetapi, karena saya tidak dapat menentukan Dockerfile, saya harus membuat scripts/build file yang melakukan docker build < Dockerfile.build dan kemudian me-mount volume Host dengan docker run -v ... untuk menjalankan build (karena saya tidak dapat menggunakan ADD w/ piped-in Dockerfiles). Saya ingin melakukan sebaliknya hanya dapat menjalankan docker build -t foobar/builder -f Dockerfile.build , docker run foobar/builder , docker build -t foobar/runtime , docker run foobar/runtime dan cukup gunakan perintah ADD di kedua Dockerfiles.
2. Dengan instruksi ONBUILD, saya ingin dapat menempatkan Dockerfiles ke dalam subdirektori (atau memiliki file Dockerfile.env, dll. di root) yang memiliki root Dockerfile dalam instruksi FROM mereka, tetapi masih dapat menggunakan root proyek sebagai konteks pembangunan mereka. Ini berguna untuk, misalnya, memasukkan parameter konfigurasi untuk lingkungan yang berbeda. Root Dockerfile masih akan menghasilkan wadah yang berguna, tetapi yang lain akan membuat varian berbeda yang kita butuhkan.

Jadi saya kira hal yang sangat saya sukai adalah dapat memisahkan konsep "konteks bangun" dari "lokasi/nama Dockerfile." Ada banyak cara potensial untuk melakukan itu, tentu saja, tetapi ini tampaknya relatif mudah bagi saya.

@ cap10morgan ada kemungkinan Anda bisa mengarahkan saya ke contoh 1 Anda, atau sesuatu yang mendekatinya? Jadi saya bisa bermain-main dan memastikan kita membicarakan hal yang sama.

@shykes https://github.com/shykes bukankah impian portabilitas ini persis
itu untuk apa indeks gambar? Mengapa membangun lingkungan perlu
portabel juga?

Beberapa proses pembangunan membutuhkan lebih dari apa yang mungkin dilakukan dengan vanilla
file docker. Lebih lanjut, menegakkan satu Dockerfile per konteks (itulah yang
permintaan ini bertujuan untuk memperbaiki) sangat membatasi.

Ini sangat mempengaruhi tim kami. Dalam pengaturan kami, kami ingin menghasilkan banyak
gambar dari "konteks" yang sama. Dengan menambahkan opsi --file dapat kita lakukan
apa yang benar-benar ingin kami lakukan - yaitu menambahkan foo.docker dan bar.docker
ke root repositori kami. Sebagai gantinya, kami akhirnya menulis skrip bash untuk disalin
berton-ton file ke lokasi sementara untuk membuat konteks, dan mengganti nama kami
file docker bernama ke dalam keajaiban Dockerfile supaya docker build bisa
kerja.

Bagi saya, lingkaran ini ada tanpa alasan yang bagus. Jika seseorang di tim kami ingin
untuk membuat gambar kami, mereka perlu menjalankan skrip khusus untuk menyelesaikan pekerjaan -
hal persis yang menurut Anda dapat Anda hindari dengan tetap berpegang pada batasan ini.

Pada Mon, Apr 7, 2014 at 4:23, Salomo Hykes [email protected] :

@cap10morgan https://github.com/cap10morgan jika ada kesempatan yang bisa Anda tunjukkan
saya untuk contoh Anda 1, atau sesuatu yang mendekati itu? Jadi saya bisa bermain
sekitar dan pastikan kita membicarakan hal yang sama.

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

@shykes karena ini tampaknya 'tidak diperbaiki', dapatkah Anda menunjuk ke dokumen atau penjelasan tentang cara bersertifikat Docker untuk menangani masalah ini?

Kasus penggunaan saya adalah saya memiliki aplikasi yang ingin saya buat dengan buruh pelabuhan di mana tes memiliki persyaratan yang berbeda dari gambar produksi. Saya pikir ini cukup umum.

Ini dan masalah .dockerignore (https://github.com/dotcloud/docker/pull/3452) (menyalin seluruh direktori .git saya ke konteks build) adalah poin nyeri kritis pertama yang saya tekan ketika mencoba docker untuk satu proyek kami selama beberapa hari terakhir dan sepertinya tidak ada yang punya otak bagi saya tetapi tampaknya ada dorongan balik pada masalah ini.

+1 membutuhkan ini juga - kami memiliki basis kode tunggal dengan beberapa layanan mikro sedang dikembangkan di sana. Kami ingin dapat menghasilkan banyak gambar, misalnya, satu gambar yang berisi services/base/* dan services/fooservice/* ; dan gambar lain yang berisi services/base/* dan services/barservices/* dan juga staticfiles/*.
Kami tidak dapat menempatkan Dockerfiles di dalam folder layanan karena Docker memperlakukan folder itu sebagai konteks saat itu dan kami tidak dapat MENAMBAH apa pun yang lebih tinggi dalam struktur folder. Kami tidak dapat menempatkan dua file Docker di root karena mereka akan memiliki nama yang sama.
Satu-satunya solusi yang kami miliki adalah menempatkan Dockerfile di folder layanan dan kemudian menulis skrip khusus untuk mengurai Dockerfile yang dipilih, menentukan jalur apa yang ingin ditambahkan (semua ditentukan relatif terhadap root proyek), lalu menyalinnya ke yang baru folder sementara, salin Dockerfile yang dipilih ke root folder baru itu dan akhirnya jalankan "docker build tempfolder". Apakah itu BENAR-BENAR perlu?
Akan jauh lebih sederhana jika Anda bisa memberi tahu "docker build" secara terpisah di mana Dockerfile dan di mana konteksnya.

Mengalami masalah ini juga .. akan senang melihat semacam perbaikan.

+1, pengkodean di sekitar batasan ini sangat merepotkan.

+1 untuk -f flag yang menentukan jalur Dockerfile terpisah dari konteks build

Docker adalah alat yang hebat tetapi penggabungan konteks yang ketat dan Dockerfile spesifik ini pasti sedikit menodai tim Docker. Struktur direktori tidak selalu mencerminkan struktur 'wadah/sub sistem' dengan tepat.

Seberapa sulit untuk memperbaikinya? Dan, ada beberapa PR untuk ini, tetapi diabaikan.

Tambahan sederhana terkait adalah memiliki file abaikan untuk hal-hal yang tidak ingin kami tambahkan ke konteks -- ya, saya melihat Anda, .git ...

Ini mungkin benar-benar membuat saya melewatkan Docker untuk saat ini, dan kembali ke Vagrant + Ansible. Bagus.

@davber .dockerignore ada di -> #6579

Tapi, ya, manajemen kontribusi sedikit menyakitkan saat ini dan salah satu hal menyedihkan yang jarang terjadi tentang buruh pelabuhan sejauh ini. Saya pikir mereka hanya kewalahan sedikit semoga.

Tim Docker, bagaimana orang bisa mendapatkan hal-hal seperti ini ditinjau dan masuk? Jika ada pemikiran yang jelas tentang mengapa ini benar-benar buruk, dan bagaimana proyek harus menghindari masalah ini, kami akan senang mendengarnya, tetapi ini sepertinya masalah sederhana untuk dijelaskan dan masalah sederhana untuk dipecahkan.

/cc @shykes @creack @crosbymichael @vieux

+1 untuk -f bendera. Juga variabel lingkungan DOCKERFILE untuk mengganti pengaturan build.

@jakehow ya pasti ada unsur kewalahan, untuk setiap pengelola setidaknya ada 1.000 orang yang secara aktif meminta sesuatu, dan menuntut penjelasan rinci mengapa hal itu belum dilakukan. Kami benar-benar melakukan yang terbaik, dan jika Anda mengunjungi saluran irc #docker dan #docker-dev, Anda akan menyaksikan firehose secara langsung.

Tetapi dalam kasus ini ada jawaban yang jelas mengapa lebih baik menyimpan pemetaan 1-1 dari Dockerfile dan direktori sumber. Saya akan mengulanginya sekali lagi: kami ingin mempertahankan properti penggambaran diri dari bangunan buruh pelabuhan. Fakta bahwa Anda dapat menunjuk ke direktori kode sumber, _tanpa informasi lain di luar band_, dan membangun gambar darinya persis dengan spesifikasi pengembang hulu, sangat kuat dan merupakan pembeda utama Docker.

Tentu, dapat secara dinamis menggabungkan direktori X dengan Dockerfile Y on-the-fly agak nyaman (walaupun saya tidak pernah merasakan kebutuhan yang membara untuk itu, dan saya sering menggunakan Docker). Tapi itu membuatnya terlalu mudah untuk melakukan sesuatu yang bodoh - yaitu, untuk mematahkan sifat penggambaran diri dari bangunan Anda. Dan itu tampak seperti tradeoff yang sangat buruk. Oleh karena itu keputusan untuk tidak mengimplementasikan fitur ini.

Adapun contoh "1 sumber repo, banyak gambar", ya, saya sangat setuju bahwa itu diperlukan. Yang kami butuhkan adalah cara standar Docker untuk direktori sumber tunggal untuk menentukan beberapa target build. Itu bisa dilakukan dengan Dockerfile multi-bagian, atau dengan beberapa Dockerfiles _asalkan ada konvensi nama file yang terdefinisi dengan baik yang memungkinkan Dockerfiles ini terdaftar dan dipilih dengan cara yang tidak ambigu_.

Jika seseorang ingin berkontribusi, kami ingin menggabungkannya. Dan seperti biasa kami akan dengan senang hati membantu kontributor pertama kali, datang menyapa di IRC dan kami akan membantu Anda memulai.

@davber Saya mendapat kesan bahwa Vagrant memiliki batasan yang sama dari 1 file deskripsi per proyek (mungkin karena alasan yang sama). Bagaimana beralih kembali ke Vagrant menyelesaikan masalah Anda dengan tepat?

@gabrtv apakah Anda ingin mencoba dan mengembalikan multi-gambar? Berikut proposal tentatif:

$ ls | grep Dockerfile
Dockerfile
db.Dockerfile
frontend-prod.Dockerfile
frontend-dev.Dockerfile
$ docker build -t shykes/myapp .
Successfully built shykes/myapp/db
Successfully built shykes/myapp/frontend-dev
Successfully built shykes/myapp/frontend-prod
Successfully built shykes/myapp
$ docker build -t shykes/myapp2 --only frontend-dev .
Successfully built shykes/myapp2/frontend-dev

Proposal itu akan bekerja dengan baik untuk kami dan saya dapat melihatnya memecahkan masalah lain untuk orang lain juga.

@shykes Saya tidak berpikir bahwa saya membeli bahwa meningkatkan kompleksitas format Dockerfile adalah tradeoff yang berharga untuk menjaga satu Dockerfile.

Ambil contoh makefiles - lebih umum daripada tidak untuk sebuah proyek memiliki 'Makefile' tetapi make juga memungkinkan Anda untuk menentukan dengan '-f' makefile yang berbeda.

Saya juga berpikir bahwa pemetaan 1: 1 antara folder sumber dan gambar kurang berguna daripada yang Anda lihat - saya telah menemukan bahwa itu umum untuk membuat folder build dan membangun dari dalamnya untuk menjaga jumlah data yang disalin ke dalam konteks ke a minimum, dan dengan demikian gambar yang lebih kecil.

Anda mengatakan "Jadi pertanyaan saya adalah: bukankah kita mengambil risiko memiliki banyak repositori sumber yang tidak dapat dibangun berulang kali dengan docker build ,"

Tapi saya pikir ini sudah terjadi, beberapa persyaratan proyek berarti bahwa satu cara untuk membangun tidak praktis, dan sintaks Dockerfile tidak memungkinkan banyak konfigurasi (berdasarkan desain dan saya tidak ingin itu berubah ...).

Saya juga tidak terlalu menyukai saran --only. Saya pikir default yang /want/ ketika mereka membangun adalah untuk konteks tertentu yang akan dibangun, bukan segalanya - ketika saya menjalankan docker build, saya ingin /only/ Dockerfile dijalankan. Tetapi saya juga ingin kemampuan untuk memiliki citra lain yang /dapat/ dapat dibangun.

Sesuai pemahaman saya, masalahnya di sini terletak pada kenyataan bahwa ketika
pemipaan Dockerfile (cat Dockerfile | docker build -) kita kehilangan pekerjaan
direktori untuk ADD dan CP.

Akan menyelesaikan masalah dengan menambahkan flag untuk build buruh pelabuhan yang memungkinkan kita untuk
tentukan di mana isi folder sumber berada?

cat Dockerfile | docker build --cwd=~/my_docker_data_files -

Dalam proposal ini, flag --cwd menentukan folder dasar untuk ADD dan CP
perintah.

29-06-2014 19:42 GMT+10:00 Peter Braden [email protected] :

Anda mengatakan "Jadi pertanyaan saya adalah: bukankah kita mengambil risiko memiliki banyak sumber?
repositori yang tidak dapat dibangun berulang kali dengan docker build ,"

Tapi saya pikir ini sudah terjadi, beberapa persyaratan proyek berarti bahwa
satu cara untuk membangun tidak praktis, dan sintaks Dockerfile tidak
memungkinkan banyak konfigurasi (berdasarkan desain dan saya tidak mau
bahwa untuk mengubah ...).

Saya juga tidak terlalu menyukai saran --only. Saya pikir default
bahwa orang /ingin/ ketika mereka membangun adalah untuk konteks tertentu yang akan dibangun,
tidak semuanya - ketika saya menjalankan docker build, saya ingin /only/ the Dockerfile untuk
dijalankan. Tapi saya juga ingin kemampuan untuk memiliki gambar lain yang /bisa/ menjadi
dibuat.

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

@llonchj sebenarnya https://github.com/dotcloud/docker/pull/5715 menyelesaikannya (dengan cara tertentu) dan itu sudah digabung menjadi master.

@shykes pasti terbuka untuk PR multi-gambar lainnya, meskipun setelah melihat #5715 saya bertanya-tanya apakah PR khusus ini relevan lagi.

Per komentar asli @peterbraden ...

Akan menyenangkan untuk dapat menentukan [perintah disunting] sehingga saya dapat MENAMBAHKAN file, dan juga memiliki beberapa file docker.

Per @cap10morgan...

Jadi saya kira hal yang sangat saya sukai adalah dapat memisahkan konsep "konteks bangun" dari "lokasi/nama Dockerfile."

Bukankah itu yang dilakukan #5715? Seperti yang saya pahami:

$ cd myapp
$ ls Dockerfile
Dockerfile
$ docker build -t gabrtv/myimage
Successfully built gabrtv/myimage
$ ls subfolder/Dockerfile
Dockerfile
$ tar -C subfolder -c . | docker build -t gabrtv/myotherimage -
Successfully built gabrtv/myotherimage

Saya tahu ini tidak menyelesaikan build multi-gambar dari root repo (yang saya setujui akan menyenangkan), tetapi bertanya-tanya apakah PR/implementasi khusus ini dapat diistirahatkan sekarang dengan #5715 .

@gabrtv Sepertinya saya #5715 tidak sesuai dengan kriteria @shykes untuk memiliki satu perintah yang akan selalu berfungsi. tar -C subfolder -c . | docker build -t gabrtv/myotherimage - , bagi saya, sangat tidak jelas.

Selain itu, ini menimbulkan kendala yang mengganggu (jika tidak berat) pada pengembang terkait tata letak repo. Tidak dapat diperbaiki, tetapi "Oh, dan saya harus mengatur ulang seluruh repo" tidak akan membantu siapa pun untuk meyakinkan bos mereka untuk beralih ke Docker.

Saya pribadi sangat menyukai saran terbaru dari @shykes , dengan kemungkinan beberapa file .dockerfile (mengapa tidak hanya .docker?), semuanya dibangun secara default. Ini membuatnya mudah untuk bangun dan berjalan dengan satu perintah apa pun yang terjadi, dan optimalkan nanti.

Bergantung pada implementasinya, seseorang dapat mengunggah konteks build hanya satu kali untuk ini di semua gambar, yang akan mengurangi biaya pembuatan banyak gambar. Karena saya tidak memiliki .dockerignore, konteks build saya beberapa ratus megabyte dan saya harus menunggu cukup lama untuk mengupload konteks saya, jadi ini akan menyenangkan.

@rattrayalex percayalah, saya setuju dengan tujuan "memiliki satu perintah yang akan selalu berhasil". Ada kemungkinan besar saya akhirnya akan menulis kode dan mengirimkan PR. :mengedip:

Maksud saya adalah dari sudut pandang organisasi proyek, kita harus berdiskusi di tempat lain daripada pada masalah berlarut-larut berjudul Allow specifying of a dockerfile as a path, not piping in :

1. Sebagian besar diskusi di sini tidak terkait dengan @shykes proposal baru di https://github.com/dotcloud/docker/issues/2112#issuecomment -47448314
2. Masalah mendasar asli (memisahkan konteks build dari Dockerfile) ditangani oleh #5715, meskipun mungkin tidak disukai semua orang

Mengutip @llonchj...

Sesuai pemahaman saya, masalahnya di sini terletak pada kenyataan bahwa ketika mem-pipe Dockerfile (cat Dockerfile | docker build -) kita kehilangan direktori kerja untuk ADD dan CP.

Dengan kata lain, jika Anda setuju dengan docker build -t <image> -f <path-to-dockerfile> , Anda dapat menggunakan tar -C <path-to-context> -c . | docker build -t <image> - sebagai solusi yang setara secara fungsional hingga kami dapat menyusun PR untuk proposal @shykes .

Saya sarankan kita menutup ini dan memulai diskusi baru di tempat lain (milis? masalah baru?).

Terima kasih kepada semua orang yang ikut campur dalam masalah ini hari ini:

@shykes terima kasih atas alasannya. Saya pikir alasan kami untuk menginginkan ini (orang lain dapat berpadu) adalah dalam pengalaman kami: Setiap aplikasi membutuhkan informasi out of band untuk berjalan dalam konteks yang dipilih. Semua aplikasi kami memiliki lebih dari satu konteks. Cara pembangunan buruh pelabuhan terstruktur memaksa pengembang aplikasi untuk memindahkan pengetahuan tentang informasi tersebut ke dalam struktur repositori mereka, atau membuat skrip pembangunan khusus yang mengesampingkan perilaku pembangunan buruh pelabuhan yang berisi informasi tersebut.

@gabrtv Saya pikir hampir semua diskusi di sini terkait secara khusus dengan masalah ini, dan senang melihatnya akhirnya dibahas di sini. Judul masalah dan beberapa posting 'penemuan' mungkin sedikit tidak relevan, jadi masalah baru atau PR dengan awal yang bersih yang merujuk pada yang satu ini mungkin bagus.

Proposal dari komentar @shykes terdengar seperti solusi bagi saya, apakah ada pekerjaan sebelumnya yang dilakukan di suatu tempat yang dapat diambil atau dilihat untuk referensi?

Bukankah "Dockerfile.frontend-prod" akan lebih baik sehingga semua Dockerfiles
dalam direktori secara alami mengurutkan bersama?

Maaf, tapi itu hanya konyol. Jika repo saya membangun 100 layanan, saya tentu tidak ingin memiliki 100 file Docker di root. (Contoh: repo dotCloud PAAS.)

Saya juga tidak ingin satu Dockerfile besar dengan 100 bagian.

Saya ingin 100 Dockerfiles, dan saya ingin mereka di direktori terpisah.

(Dan tidak, saya tidak bisa hanya membangun setiap layanan di direktorinya sendiri, karena hampir semua layanan akan menggunakan kode umum dan pustaka yang hidup _di luar_ direktori setiap layanan.)

Sekali lagi, saya tidak mengerti mengapa memiliki flag tambahan untuk menentukan path ke Dockerfile (default hanya Dockerfile ) adalah masalah besar?

Selain itu, proposal saat ini ( <imagename>.Dockerfile ) tidak memetakan sama sekali dengan desain Pembuatan Otomatis saat ini. Jika satu repo di salah satu sistem build saya terganggu, penyerang dapat membebani semua repo saya...?

@jpetazzo seperti kebanyakan orang yang masuk akal, saya menerima ketidaksepakatan tetapi tidak suka disebut konyol. Silakan berusaha untuk menyajikan argumen Anda tanpa menghina kecerdasan rekan-rekan Anda. Terima kasih.

_Sekali lagi, saya tidak mengerti mengapa memiliki bendera tambahan untuk menentukan jalur ke Dockerfile (default hanya Dockerfile) adalah masalah besar?_

Saya membuat argumen khusus di atas. Jangan ragu untuk membacanya dan menyajikan argumen tandingan.

Re: berantakan. @gabrtv memiliki perhatian yang sama pada IRC. Setelah beberapa diskusi kami datang dengan alternatif ini:

$ ls Dockerfile Dockerfiles/*
Dockerfile
Dockerfiles/frontend-prod
Dockerfiles/frontend-dev

Ide yang sama, tetapi lebih sedikit file individual yang tergeletak di repo root.

Selain itu, proposal saat ini (.Dockerfile) tidak memetakan sama sekali dengan desain Automated Builds saat ini. Jika satu repo di salah satu sistem build saya terganggu, penyerang dapat membebani semua repo saya...?

Nah, bagaimana nama mereka sekarang? Jika Anda memiliki repo bernama "abc" hanya dengan Dockerfile biasa, maka masuk akal jika gambar yang dihasilkan oleh yang diberi nama "abc". Jika Anda memiliki repo "xyz" dengan "Dockerfile.abc" dan "Dockerfile.zzz" di dalamnya, maka masuk akal jika Anda memberi nama build dari itu sebagai "xyz-abc" dan "xyz-zzz".

Saya berada dalam situasi yang sama seperti Anda juga (banyak layanan masing-masing di sub-folder mereka sendiri dengan bagian umum) dan opsi eksplisit untuk mengatur Dockerfile untuk digunakan pada waktu pembuatan akan membuat pemikiran saya lebih mudah, tetapi kemudian saya juga dapat melihat bagaimana saya bisa menggabungkan proposal "Dockerfile.*" dengan "file tar sebagai konteks" yang sudah dirilis untuk bisa mendapatkan apa yang saya inginkan - root dockerfiles untuk setiap layanan akan menghasilkan gambar build mereka (dengan kompiler dan lainnya) dan kapan itu dijalankan mereka akan menampilkan tar konteks dengan executable yang sudah dikompilasi dan Dockerfile produksi (diambil dari folder layanan itu sendiri) yang akan menggambarkan gambar hanya dengan dependensi runtime.

Sebenarnya saya sekarang bahkan menulis ini dengan satu root Dockerfile karena lingkungan build saya kurang lebih sama untuk semua layanan dan saya dapat dengan mudah memberikan parameter saat runtime untuk memberi tahu tar konteks rilis layanan mana yang ingin saya buat.

@shykes baik, jika kita sampai sejauh itu untuk memiliki Dockerfile/* , lalu mengapa tidak melangkah lebih jauh dan memiliki "docker build" cukup cari file bernama "Dockerfile.*" di semua subfolder dari direktori saat ini, secara rekursif, dan menjalankan semuanya dalam konteks direktori saat ini? Dan sementara kita berada di if, berikan opsi untuk hanya membangun salah satunya ... seperti "-f"? :)

... tidak suka disebut konyol

Saya tidak tahu bahwa "konyol" bisa dianggap menyinggung; Saya hanya bermaksud "canggung" mungkin, dan karena itu mohon maaf karena menyalahgunakan kata itu.

Saya pikir argumen spesifik Anda adalah "Saya tidak ingin orang mulai meletakkan Dockerfiles di tempat-tempat acak dan secara sistematis menggunakan -f ketika itu tidak benar-benar diperlukan". Apakah itu benar? Dalam hal ini, masuk akal untuk mengamanatkan satu Dockerfile di bagian atas repo, mencantumkan Dockerfile lainnya. Jika file tersebut tidak ada, builder dapat menolak untuk beroperasi (atau mengeluarkan peringatan), dan jika hanya mencantumkan satu Dockerfile, builder juga dapat mengeluarkan peringatan. Saya tidak berpikir bahwa paralel dengan -v dan -p sesuai di sini.

@aigarius jika kita melakukannya akan kurang jelas bagaimana memetakan setiap sub-Dockerfile ke gambar anak. Keuntungan dari ./Dockerfile.* dan ./Dockerfiles/* adalah bahwa keduanya memetakan ke satu namespace yang dapat kita gunakan untuk menamai gambar yang dihasilkan. Sebaliknya, jika saya memiliki ./foo/Dockerfile.db dan ./bar/Dockerfile.db , dan saya docker build -t shykes/myapp . , yang mana yang dipanggil shykes/myapp/db ?

yang mana yang dipanggil shykes/myapp/db?

Juga tidak. Dalam skenario seperti itu, Anda akan menyandikan path lengkap ke Dockerfile ke dalam nama, jadi Anda akan memiliki "shykes/myapp/bar/db" dan "shykes/myapp/foo/db". _does_ ini menjadi tidak nyaman dekat dengan namespace Java, tetapi saya akan menyerahkan kepada orang lain untuk memutuskan apakah itu baik atau buruk.

@shykes : tentang Vagrant, yah saya, dan kemungkinan besar beberapa lainnya, gunakan Vagrant untuk beberapa fungsionalitas Docker yang tumpang tindih. Jadi, bagi saya, saya perlu diyakinkan bahwa build multi-mesin saya saat ini -- yang saya lakukan di Vagrant, dengan beberapa definisi mesin -- tidak menjadi lebih canggung saat menggunakan Dockerfiles. Masalahnya adalah "konteks" jauh lebih fleksibel di Vagrant, di mana saya bisa dengan cepat mendapatkan konteks dari lokasi mana pun dengan direktori bersama, dan begitu juga bahasanya, jadi jika saya hanya ingin membangun satu layanan (atau mesin) Saya dapat mengatur variabel lingkungan dan 'menyediakan/menyediakan' itu. Saya menggunakan metode itu setiap hari untuk membuat atau menyediakan beberapa layanan di sistem saya. Dan, jika saya terlalu kesal dengan Vagrantfile yang berkembang, saya dapat dengan mudah 'memuat' sub-Vagrantfile yang menjelaskan layanan atau aspek individual.

Mengenai saran konkret untuk menangani banyak file Docker, ya, itu akan memungkinkan kami untuk membagi logika kami untuk layanan individual. Besar. Tapi, saya sering ingin atau perlu membangun satu layanan secara terpisah, jadi saya masih perlu menentukan satu Dockerfile tertentu...

Jadi, masalah saya di sini ada dua:

1. Tidak mendapatkan file besar yang berantakan untuk semua layanan
2. Mampu membangun satu layanan spesifik dalam file/cluster file itu

Sekali lagi, Docker adalah ide dan alat yang jenius, jadi saya INGIN orang-orang seperti saya menyerah pada Vagrant untuk jenis fungsi atau kasus penggunaan tertentu.

Maaf jika saya mengulangi sesuatu yang diperlakukan secara menyeluruh di atas, tetapi saya gagal melihat bagaimana solusi apa pun lebih baik daripada mendukung opsi '-f'. Yaitu, masalah implementasi modulo karena beberapa ketergantungan yang mengakar pada Dockerfile yang berada di root konteks, saya tidak melihat ada kerugian dengannya.

Dengan opsi '-f', seseorang pasti dapat menyusun sub direktori dan sub Dockerfile sesuka hati, seperti pendekatan Dockerfiles/ di atas. Ya, seseorang kemudian akan membutuhkan basher satu baris sederhana untuk meniru perilaku yang tepat ...

Tampaknya ada ketegangan antara berbagi dan fleksibilitas.

Jika berbagi adalah fitur yang paling penting, maka ya, file docker standar
masuk akal.

Saya tidak berpikir berbagi adalah fitur yang paling penting. Berbagi tercapai
melalui gambar.

Selanjutnya, kami menggunakan buruh pelabuhan pada proyek yang secara eksplisit TIDAK dapat dibagikan. Di dalam
fleksibilitas kasus ini jauh lebih berharga bagi kami. Kedengarannya seperti banyak di
benang apapun berada di posisi yang sama ini.

Opsi -f bertujuan memberi kita fleksibilitas yang kita butuhkan. Di sisi lain,
mampu menentukan jalur absolut untuk konteks pembangunan juga akan
kerja.
Pada 3 Juli 2014 18:00, "David Bergman" [email protected] menulis:

Maaf jika saya mengulangi sesuatu yang diperlakukan secara menyeluruh di atas, tetapi saya gagal melihat
bagaimana solusi apa pun lebih baik daripada mendukung opsi '-f'. Yaitu, modulo
masalah implementasi karena beberapa ketergantungan yang mengakar pada
Dockerfile yang berada di root konteks, saya tidak melihat ada kerugian dengan
dia.

Dengan opsi '-f', seseorang pasti dapat menyusun sub direktori
dan sub Dockerfiles sesuka hati, seperti Dockerfiles/
pendekatan di atas. Ya, seseorang kemudian akan membutuhkan basher satu baris sederhana untuk
meniru perilaku yang tepat ...

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

Setuju bahwa -f memberikan fleksibilitas paling banyak dengan "kejutan" minimal (saya pribadi berasumsi ada bendera seperti itu dan mencobanya sebelum datang ke utas ini).
Menambahkan -c , baik dari direktori atau tar, untuk memberikan konteks juga sepertinya merupakan tambahan yang bagus. Ini akan menghapus konstanta cd s dari proses pembangunan besar, misalnya; di perusahaan.

Lebih jauh lagi, README yang berisi instruksi ke docker build -f foo/bar/Dockerfile -c foo/ tidak terdengar seperti akan mengganggu saya.
Juga setuju bahwa docker build dapat dengan mudah mencari Dockerfile s. Dengan cara ini, repo terstruktur seperti ini:

-- README
-- foo/
---- Dockerfile
---- etc
-- bar/
---- Dockerfile
---- etc
---- subbar/
------ Dockerfile
-- context/
---- etc

akan menghindari kemungkinan konflik penamaan ( repo/bar/subbar ), mudah untuk menghitung jumlah, dan harus masuk akal dalam banyak konteks dev. Ini akan memungkinkan penggunaan yang mudah dari docker build , yang akan membangun banyak konteks, dan docker build -f , yang dapat menghilangkan Dockerfile asing di sebagian besar konteks.

Jika -f adalah file aa daripada dir yang berisi Docker, itu juga akan berfungsi, sehingga pengembang dapat memiliki file docker yang tidak dibuat ketika docker build dijalankan.

Agar ini tidak hilang, kemarin dalam diskusi IRC dengan

• Ada master Dockerfile di root repositori yang hanya berisi beberapa baris dalam format baru seperti "TERMASUKKAN foo/bar/Dockerfile AS bar-foo" untuk setiap gambar yang akan dihasilkan
• Setiap sub-proyek (seperti modul bar dari subproyek foo), yang membutuhkan gambar terpisah, memelihara Dockerfile biasa di foo/bar/Dockerfile. Jalur di Dockerfile itu (untuk ADD dan COPY) masih relatif terhadap root konteks, yang merupakan root dari repositori (tempat master Dockerfile berada)
• Panggilan reguler ke "docker build -t mycorp/myapp ." akan membuat semua gambar yang terdaftar di root Dockerfile dan memberinya nama seperti "mycorp/myapp/bar-foo" dalam contoh ini
• Opsi baris perintah tambahan untuk "docker build" perlu diperkenalkan untuk hanya membangun beberapa gambar yang dideklarasikan, seperti "docker build -t mycorp/myapp --only bar-foo,baz-db"

Untuk berjaga-jaga jika orang masih mencari solusi:

#!/bin/bash
ln -s Dockerfile-dev Dockerfile
docker build -t image/name-dev:latest .
rm Dockerfile

@shykes ping? Jika ada persetujuan pengembang inti untuk solusi desain tertentu, kemungkinan besar seseorang akan mencoba mengimplementasikannya dan membuat permintaan tarik.

+1 ke solusi -f, Sementara saya setuju setiap repo secara teori harus menggunakan layanannya sendiri. Beberapa orang tidak memiliki kemewahan solusi itu. Masalah khusus saya adalah saya memiliki repo koki dengan banyak buku masak di dalamnya, dan saya harus dapat membangun banyak layanan. Tapi saya harus bisa TAMBAH direktori di atas. Jadi menjaga konteks di root dan menunjuk ke file buruh pelabuhan di subdirektori adalah optimal.

"-f" mungkin tidak akan diimplementasikan karena alasan yang sudah diberikan.

Sangat penting bahwa build bekerja persis sama dari host ke host, dan memiliki hal-hal yang bergantung pada pengaturan host dengan cara tertentu (yaitu, Dockerfile di beberapa tempat acak dan konteks di beberapa tempat lain) melanggar kontrak ini.

Saya pikir #7115 mungkin adalah solusi yang tepat untuk ini

Ada juga #7204 yang juga cocok dengan banyak kasus penggunaan untuk ini, saya pikir.

Saya tidak menyukai kedua dari 2 solusi yang diusulkan yang melibatkan penambahan sintaks ke file docker. Tak satu pun dari mereka tampak langsung. #7115 sepertinya masih tidak akan menyelesaikan kasus penggunaan di mana saya ingin menghasilkan beberapa jenis gambar dari satu repo, seperti yang saya lakukan, misalnya, di salah satu proyek saya untuk menghasilkan gambar 'tes' dan gambar 'prod'. #7204 sepertinya solusi yang terlalu rumit yang memecahkan masalah yang berbeda -f memungkinkan _configurability_ untuk membangun, sedangkan kedua solusi ini mengatasi _sub_builds_.

Saya sangat ingin penjelasan tentang "Sangat penting bahwa build bekerja persis sama dari Host ke Host". Saya tidak mengerti mengapa ini adalah prinsip kunci.

Karena itu, saya menggunakan make untuk menghasilkan lingkungan buruh pelabuhan sebagai solusi untuk seluruh masalah ini, yang sepertinya sudah melanggar perintah run-the-sama Host-to-Host Anda.

Bagi saya, -f tampak seperti solusi pragmatis, tetapi jika tidak dapat diterima, maka mungkin kita dapat memikirkan solusi yang tidak melibatkan mengubah dockerfile menjadi sintaks pemrograman yang lengkap.

Sangat penting bahwa build bekerja persis sama dari host ke host

Saya juga ingin mendengar lebih banyak tentang mengapa ini adalah kuncinya. Tim kami saat ini
dipaksa untuk membuat skrip proses pembuatan - hal persis yang Anda coba hindari.

Ketika saya mengunduh gambar dari registri, itu hanya berfungsi. Saya tidak perlu
bangun itu. Bukankah itu mencapai pengulangan host-to-host? Mengapa membangun?
juga harus host-to-host berulang?

Pada Senin, 28 Juli 2014 pukul 10:43, Peter Braden [email protected]
menulis:

Saya tidak suka kedua dari 2 solusi yang diusulkan yang melibatkan penambahan sintaks ke
file buruh pelabuhan. Tak satu pun dari mereka tampak langsung. #7115
https://github.com/docker/docker/issues/7115 sepertinya masih tidak seperti itu
akan menyelesaikan kasus penggunaan di mana saya ingin menghasilkan beberapa jenis gambar
dari satu repo, seperti yang saya lakukan, misalnya, di salah satu proyek saya untuk
menghasilkan gambar 'test' dan gambar 'prod'. #7204
https://github.com/docker/docker/pull/7204 sepertinya dan
solusi yang terlalu rumit yang memecahkan masalah yang berbeda -f memungkinkan
_configurability_ ke build, sedangkan kedua solusi ini membahas
_sub_builds_.

Saya sangat ingin penjelasan tentang "Sangat penting bahwa sebuah bangunan berfungsi
persis sama dari host ke host". Saya tidak mengerti mengapa ini adalah kunci seperti itu
prinsip.

Karena itu, saya menggunakan make untuk menghasilkan lingkungan buruh pelabuhan sebagai
solusi untuk seluruh masalah ini, yang sepertinya sudah melanggar
Host-to-Host menjalankan imperatif yang sama.

Bagi saya, -f sepertinya solusi pragmatis, tetapi jika tidak dapat diterima,
maka mungkin kita bisa memikirkan solusi yang tidak melibatkan memutar
dockerfile menjadi sintaks pemrograman yang lengkap.

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

Sejauh yang saya pahami, ide utamanya adalah Anda dapat menarik git repo dan jika Anda melihat Dockerfile di sana, maka Anda dapat menjalankan "docker build -t mytag ." di dalamnya dan dapatkan build penuh yang diharapkan. Kuncinya di sini adalah tidak ada instruksi pembuatan khusus yang mungkin salah atau tidak diketahui orang.
Apa yang _bisa_ menjadi kompromi adalah cara untuk mendefinisikan beberapa gambar Docker dalam satu konteks di mana secara default semuanya dibangun dengan sub-tag yang telah ditentukan sebelumnya dan kemudian Anda dapat memiliki opsi untuk membuat hanya satu dari banyak gambar yang mungkin.
Dengan cara ini sintaks build umum dipertahankan sementara juga memungkinkan keduanya: 1) menghasilkan banyak gambar berbeda dari satu konteks; 2) hanya memilih untuk membuat salah satunya dengan opsi "lanjutan".
Sintaks yang diusulkan dijelaskan dalam komentar saya di atas - https://github.com/docker/docker/issues/2112#issuecomment -48015917

@algarius terima kasih, saya pikir pada titik ini kita harus membuka proposal desain baru untuk sintaks _INCLUDE_. Untuk contoh proposal desain lihat #6802 atau #6805.

Prosesnya terlihat seperti ini:

• Kirim proposal desain
• Diskusikan proposal desain
• Saya menyetujui proposal desain
• Kirim PR untuk proposal desain

Jujur saja, build tidak benar-benar dapat diulang sekarang.

Jika saya memiliki RUN apt-get update && apt-get install build-essentials ruby python whatever di Dockerfile saya, maka saya sudah berada di bawah kekuasaan
apa pun yang "terbaru" di repo pada saat saya membuat gambar. Jika
ANDA membangun gambar seminggu kemudian, Anda mungkin mendapatkan versi yang berbeda dari
dependensi dengan yang saya dapatkan.

@codeaholics Tapi itu

Mungkin komentar yang adil

@codeaholics Anda benar bahwa pengulangan build tidak sempurna, meskipun ada opsi untuk mengendalikannya (seperti penyematan versi) dan kami harus menyediakan lebih banyak. Tapi setidaknya build selalu memiliki _entry point_ yang sama, yang berarti bahwa kami _dapat_ memperkenalkan pengulangan yang lebih baik di jalan. Namun, setelah build Anda bergantung pada alat pihak 3d di hulu Docker itu sendiri, tidak ada jalan untuk kembali: pengulangan build Anda pada dasarnya nol, dan tidak ada peningkatan Docker di masa mendatang yang dapat memperbaikinya.

Ini juga bukan hanya tentang pengulangan. Jika build Anda bergantung pada serangkaian argumen tertentu, tidak dapat ditemukan oleh _docker build_, maka alat kustom Anda adalah satu-satunya alat build di Dunia yang dapat membuatnya: Anda tidak lagi dapat memanfaatkan berbagai alat dan plugin CI/CD yang mengasumsikan _docker build_ asli yang dapat ditemukan.

@peterbraden di #7115, setelah Anda menambahkan kemampuan untuk beberapa panggilan PUBLISH , Anda sekarang dapat menghasilkan banyak gambar. Kemudian Anda dapat menambahkan konfigurasi dengan mengizinkan memilih sub-gambar mana yang akan dibuat. Kuncinya adalah konfigurabilitas terjadi _dalam set sub-gambar yang dapat ditemukan oleh Docker_. Dengan cara itu Anda mempertahankan kemampuan untuk ditemukan.

@shykes > setelah build Anda bergantung pada alat pihak 3d di hulu Docker
sendiri ... pengulangan build Anda pada dasarnya nol.

Saya setuju. Saya pikir sebagian besar file Docker saya bergantung pada apt dan repositori apt
terus berubah. Membangun hari ini tidak sama dengan membangun
kemarin. Gambar yang dibuat adalah satu-satunya imo standar emas.

Jika pengulangan bukan alasan utama pembatasan, plugin CI
dukungan tampaknya seperti mundur yang cukup lemah. Membangun alat dirancang untuk
mendukung kasus penggunaan istimewa. Sebuah plugin yang tidak lebih dari
mengkonfigurasi docker build cmd tampaknya sangat tidak berguna. Alat build saya adalah
sudah menjadi lingkungan skrip. Lebih buruk lagi, menyekop semua potensi
kasus penggunaan ke dalam Dockerfile lembur sepertinya cara yang buruk untuk arsitek
dia. Dockerfile harus tetap fokus hanya untuk menghasilkan gambar baru dengan
menambahkan lapisan ke gambar dasar. Pekerjaan lain tampaknya keluar dari band.

Saya suka Docker sejauh ini. Kerja yang luar biasa teman-teman! Masalah khusus ini terjadi begitu saja
menjadi titik sakit.

Pada Senin, 28 Juli 2014 pukul 12:25, Solomon Hykes [email protected]
menulis:

@peterbraden https://github.com/peterbraden di #7115
https://github.com/docker/docker/issues/7115 , setelah Anda menambahkan kemampuan
untuk beberapa panggilan PUBLIKASIKAN, kini Anda dapat menghasilkan banyak gambar. Terus Anda
dapat menambahkan konfigurasi dengan memungkinkan memilih sub-gambar mana yang akan dibuat.
Kuncinya adalah bahwa konfigurabilitas terjadi _dalam himpunan
sub-gambar dapat ditemukan oleh Docker_. Dengan cara itu Anda mempertahankan kemampuan untuk ditemukan.

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

@thedeeno tujuan Dockerfile adalah untuk menentukan cara mengubah repositori kode sumber menjadi sesuatu yang dapat dijalankan Docker.

Bagaimana dengan "tujuan _a_ Dockerfile adalah untuk menentukan cara mengubah repositori kode sumber menjadi sesuatu yang dapat dijalankan Docker."

Saya pikir kita dapat setuju bahwa ada kebutuhan nyata akan cara untuk memiliki banyak repo-> pemetaan gambar. Karena itu, banyak dari kita menyalahgunakan skrip shell dan makefile untuk melakukan ini. Dalam pengalaman saya, saya belum melihat banyak kustom bernama Makefiles - konfigurasi dan default adalah kekuatan yang kuat. Karena itu, saya tidak yakin bahwa orang yang menyalahgunakan konvensi adalah skenario yang realistis.

Alternatif yang Anda usulkan, menambahkan kata kunci ke sintaks Dockerfile, membuat pembuatan Dockerfiles lebih kompleks. Saya mendukung menjaga sintaks itu sesederhana mungkin. PUBLISH et al, tampak tidak elegan dibandingkan dengan sintaks Dockerfile lainnya.

Ada juga ide untuk mengikuti konvensi alat yang ada. Seperti yang telah disebutkan, -f adalah pola yang umum sehingga orang mencobanya tanpa mengetahuinya berhasil. UI harus intuitif, dan people _get_ -f menandai. Grokking sintaks Dockerfile baru hampir tidak intuitif.

@peterbraden @shykes Saya setuju -f menjadi lebih sederhana dan intuitif. Saya awalnya menemukan masalah ini karena saya _mengharapkan_ Docker sudah memiliki fitur ini dan mencarinya (mungkin ketika itu tidak berfungsi secara default) pada hari pertama saya mulai mengujinya untuk aplikasi kami.

Ini bukan kasus tepi kecuali Anda berada dalam situasi di mana Anda tidak menguji perangkat lunak Anda atau menjalankan perangkat lunak Anda di beberapa lingkungan. Setiap repo yang saya sentuh dalam 10 tahun terakhir memiliki persyaratan untuk dapat dijalankan dalam konteks yang berbeda. Saya pikir banyak orang di utas ini memiliki masalah yang sama. Kita semua sepakat (saya pikir) bahwa memiliki konvensi jelas berharga untuk konteks default untuk aplikasi Anda (dengan asumsi Anda memilikinya).

Saya membaca #7115 (cepat) dan tidak mengerti bagaimana memecahkan masalah ini bagi kita, mungkin ini adalah masalah dokumentasi pada PR tetapi jika sulit untuk berkomunikasi, itu akan menyebabkan frustrasi dan kesalahan IMO, sementara -f atau bendera serupa akan membutuhkan sedikit usaha untuk menjelaskan dan menggunakan dengan benar.

Membuat proposal baru dengan ide TERMASUK itu - https://github.com/docker/docker/issues/7277

Sebagai catatan tambahan - mungkin layak untuk memikirkan perintah "APT" yang lebih efisien daripada "RUN apt-get install -y ...." (dan kemudian YUM, EMERGE, PACMAN, dan apa pun lainnya)

Oh dan mengingat bahwa banyak orang sebenarnya hanya mencoba opsi "-f", akan lucu jika setiap kali Anda mencoba menggunakannya, Anda mendapatkan pesan kesalahan yang mengarahkan Anda ke halaman dalam dokumentasi yang menjelaskan solusi baru.

Saya benar-benar berpikir kita semua mengabaikan gajah di ruangan itu.

@shykes mengatakan hal-hal seperti "Fakta bahwa Anda dapat menunjuk ke direktori kode sumber, tanpa informasi lain di luar pita, dan membangun gambar darinya persis dengan spesifikasi pengembang hulu, sangat kuat dan a pembeda utama Docker."

Saya cukup yakin ini setara dengan mengatakan "mengetik docker build . dalam direktori harus selalu melakukan hal yang benar", yang setara dengan mengatakan "Jika Anda memiliki proyek di mana tidak ada hal yang benar untuk docker build . harus dilakukan, kamu salah"

Saya tidak dapat berbicara atas motivasi orang lain yang berlangganan masalah ini, tetapi motivasi saya sendiri untuk masalah ini adalah kasus-kasus di mana docker build . tidak memiliki perilaku yang jelas. Apakah saya menginginkan versi debug atau versi rilis? Apakah saya ingin postgres dipanggang atau haruskah saya memancarkan gambar aplikasi dan postgres yang terpisah? Apakah saya ingin memuat data uji atau data produksi? Apakah saya ingin menjalankan tes?

Tentu, saya ingin hidup di dunia di mana orang tidak perlu menjawab pertanyaan-pertanyaan ini untuk mendapatkan bangunan. Tapi aku tidak hidup di dunia itu. Tentu saja saya dapat secara sewenang-wenang memilih beberapa jawaban untuk pertanyaan-pertanyaan itu dan mendefinisikan perilaku untuk docker build . . Tetapi faktanya adalah bahwa membangun sesuatu yang sewenang-wenang ketika pengguna mengetik docker build . bukanlah "melakukan hal yang benar".

Kenyataan dari situasinya adalah bahwa ada proyek-proyek di mana tidak ada hal yang jelas benar untuk dibangun. Ada banyak cara untuk menyelesaikannya di dalam buruh pelabuhan, seperti dukungan -f , atau membuat pengguna memilih dari daftar target yang diimpor dari tempat lain, atau berbagai proposal lainnya. Tetapi mereka semua memiliki properti yang docker build . rusak, berdasarkan desain. Ada ketidakcocokan impedansi mendasar di sini, Anda tidak bisa hanya mengusulkan jalan keluar darinya.

Gagasan bahwa setiap proyek dapat memilih sesuatu yang masuk akal untuk dilakukan untuk docker build . adalah fantasi. Proyek yang tidak mungkin melakukan sesuatu yang masuk akal ada, dan jumlahnya. Satu-satunya pertanyaan pada saat ini adalah apakah Docker akan mendukung sifat multi-buildproduct dari proyek-proyek tersebut secara langsung atau apakah mereka akan kembali ke buildtool tradisional seperti make atau bahkan skrip shell. Ini terjadi sekarang : misalnya Discourse, salah satu proyek terdistribusi di Docker yang lebih besar, menggunakan sistem build buatan sendiri sebagian untuk memecahkan masalah ini.

@drewcrawford Anda tahu, itulah masalahnya. "pembuatan buruh pelabuhan." harus membangun gambar _the_. Satu-satunya gambar yang benar. Anda seharusnya mengubah parameter run docker untuk menyesuaikan perilaku satu-satunya gambar ke lingkungan yang berbeda.
Dalam konteks ini, Anda mungkin menginginkan versi rilis, hanya aplikasi, tidak ada yang lain. Semua hal lain, seperti "gambar postgres" adalah hal berbeda yang ditautkan ke aplikasi Anda saat runtime. Anda dapat mengambil gambar rilis yang sama dan menjalankannya dengan perintah non-default untuk menjalankan pengujian Anda di dalamnya.
Idealnya, dengan dukungan multiimage Anda bahkan tidak perlu memilih antara build "rilis", "debug" dan "dengan tes" - Anda hanya memiliki semuanya dengan build dasar dan 3 build perbedaan kecil di atasnya.
Jika Anda mencoba membengkokkan Docker ke cara berpikir lama, Anda akan mengalami waktu yang buruk. Jangan mencoba untuk memalu sekrup dengan obeng.

@algarius Saya pikir masalahnya adalah bahwa pemikiran ini tidak berlaku untuk aplikasi nyata, dan tidak ada yang menjelaskan bagaimana jika kita benar-benar seharusnya memiliki perubahan paradigma di sini.

Mengizinkan banyak gambar adalah cara paling sederhana dan intuitif untuk mendukung persyaratan yang dimiliki sebagian besar aplikasi yang dapat diakses jaringan dunia nyata (beberapa lingkungan dengan dependensi berbeda). Apakah membuat tata bahasa lebih rumit dengan cara yang tidak dapat dikomunikasikan untuk menyelesaikan ini diinginkan? Pada akhirnya Anda hanya merekayasa ulang dan mengaburkan fakta bahwa Anda memiliki> 1 lingkungan dengan dependensi berbeda yang dapat dengan mudah diekspresikan dengan cara sederhana seperti beberapa file Docker yang hampir tidak memerlukan penjelasan kepada pengguna akhir perangkat lunak.

@drewcrawford memberikan contoh nyata tentang bagaimana ini ditangani dalam aplikasi populer dunia nyata saat ini yang didistribusikan dengan dukungan Docker. Bagaimana seharusnya mereka melakukan ini?

@aigarius Bukannya saya tidak mengerti "cara buruh pelabuhan". Saya hanya berpikir itu salah.

Misalnya, pengujian mungkin memerlukan build yang berbeda--recompile_-yang jujur-untuk-Tuhan--karena kode logging tertentu yang terlalu lambat untuk produksi harus dikompilasi secara kondisional.

Jika ini terdengar seperti pekerjaan untuk sistem make, Anda benar--dan itulah yang sebenarnya dilakukan orang-orang seperti saya, mereka menemukan cara untuk membuat skrip docker build menggunakan sistem build yang sebenarnya.

Masalahnya di sini adalah bahwa Dockerfile tidak dapat menjadi antarmuka pengguna yang disukai untuk membangun dan juga secara substansial kurang kuat daripada misalnya make . Ini bisa berupa antarmuka pengguna yang disukai untuk membangun, dengan kekuatan mirip, atau bisa menjadi alat tingkat rendah dengan make dll. sebagai antarmuka pengguna yang sebenarnya. Tetapi sistem build "nyata" tidak rumit secara sewenang-wenang--mereka rumit karena orang menggunakan fitur-fiturnya, dan tidak ada build docker yang disederhanakan yang akan mengubahnya. Semua yang akan terjadi adalah buruh pelabuhan akan menjadi cc , yang dipanggil orang dengan make .

@shykes @drewcrawford @aigarius Saya telah menulis proposal untuk opsi -f sederhana dengan cara yang sama seperti @shykes yang dijelaskan sebelumnya di utas ini di sini: #7284

@drewcrawford Anda benar, untuk menjadi antarmuka pengguna yang disukai untuk build, docker build harus setidaknya sekuat misalnya. make . Ada 2 cara untuk melakukannya:

• 1) Kita bisa mencoba untuk mengimplementasikan kembali setiap fitur dari setiap variasi make, serta setiap alternatif untuk make di luar sana: Maven, scons, rake, dan tentu saja skrip shell lama yang bagus.

ATAU

• 2) Kami dapat mengenali bahwa alat build ini sendiri merupakan program yang dapat dieksekusi, yang berarti mereka memiliki dependensi runtime, dan dibangun dari dependensi build - dan seterusnya hingga ke bawah. Dan kami dapat menyediakan cara bagi Anda untuk _benar-benar menggunakan_ alat build favorit Anda. Jadi kita tidak perlu mengimplementasikan ulang make karena sebenarnya kita bisa membangun dan menjalankan make.

Ketika Anda mengatakan make , rasa apa yang Anda maksud? Versi yang mana? Dibangun dari svn checkout mana tepatnya? Dengan opsi build mana? Libc mana yang ditautkan? Pertanyaan yang sama untuk cc yang juga Anda sebutkan. Mungkin itu tidak masalah - mungkin aplikasi Anda akan menjadi sama persis terlepas dari versi acak make akhirnya saya gunakan untuk membangun. Tapi sekali lagi, mungkin itu penting. Mungkin satu-satunya cara bagi saya untuk mendapatkan build yang sama persis dengan Anda, adalah dengan menggunakan build Make dan Cc yang sama persis dengan yang Anda gunakan. Dan tidak ada cara mudah untuk melakukannya hari ini - tetapi itulah yang ingin saya lakukan.

Saya tidak benar-benar menganggap docker build sebagai alat build, tepatnya - lebih sebagai alat meta-build: titik awal yang diketahui dari mana Anda dapat menyusun kembali lingkungan build apa pun, dengan andal. Itulah motivasi untuk #7115.

@shykes Saya rasa tidak perlu untuk benar-benar mereplikasi _setiap_ fitur dari make, Maven, rake, dll. Lagi pula, alat ini tidak mereplikasi setiap fitur satu sama lain, dan entah bagaimana mereka cocok.

Namun, perlu (jika Docker menjadi antarmuka pengguna pilihan untuk membangun gambar) bahwa Dockerfile menjadi bahasa yang lebih ekspresif daripada saat ini.

Proposal dalam masalah ini sebenarnya adalah langkah sederhana di sepanjang garis itu: dikatakan "Kami membutuhkan yang setara untuk membuat _target_". Pertanyaan "versi make apa" tidak benar-benar masuk ke dalam gambaran--konsep "target" umum dibuat, Maven, rake, dan setiap sistem build serius lainnya. Mereka memiliki sintaks yang berbeda tetapi fakta bahwa fitur itu sendiri bersifat universal harus menjadi petunjuk bahwa ini adalah hal yang sering dilakukan orang ketika mereka membangun sesuatu.

Tidak masalah jika hal yang mereka bangun adalah program C, gambar Docker, atau apa pun di antaranya--Anda masih membangun beberapa target. Gagasan tentang target pembangunan sangat mendasar sehingga mencakup implementasi sistem pembangunan, mencakup bahasa pemrograman, mencakup sistem operasi. Kami tidak berbicara tentang mereplikasi beberapa fitur khusus GNU Make yang tidak jelas di sini, kami berbicara tentang sesuatu yang memiliki kesepakatan seluas mungkin.

Anda mencoba memperkenalkan beberapa konsep "alat meta-build" di sini tetapi tidak ada hal seperti itu. Sama seperti docker yang dapat mengatur pembuatan build, begitu juga dengan build docker yang dapat diorkestrasikan, dan sebenarnya make sedang digunakan saat ini dengan cara itu, karena tidak ada cara untuk menentukan target build ke Docker. Tetapi bagaimanapun juga, tidak ada sistem yang secara inheren lebih atau kurang meta daripada yang lain, mereka semua hanya membangun sistem, yang membangun target, tetapi dalam kasus Docker Anda hanya diizinkan satu, yang merupakan masalahnya.

Proposal seperti #7115 menarik tetapi kecuali saya melewatkan sesuatu, itu bukan pengganti yang efektif untuk target. Target memberi tahu Anda apa yang harus dibangun. #7115 memberi Anda DSL yang lebih fleksibel yang hanya dapat membangun satu hal. Itu sesuatu, tapi bukan itu yang diminta di sini.

docker build -t my_project_builder .
# Builds the builder container
docker run my_project_builder my_target | docker build -t my_project/my_target -< Dockerfile_MyTarget
# target is built, tarballed, and sent to stdout, then piped into a new docker build as the context and custom Dockerfile name

@drewcrawford hanya untuk mengonfirmasi, jika buruh pelabuhan mengizinkan sesuatu yang setara dengan Buat target, sehingga Anda dapat 1) menentukan target mana yang akan dibangun, mis. make clean; make foo , 2) default untuk membangun _semua_ target, dan 3) memiliki cara untuk menghitung target... Itu akan memuaskan Anda?

Itu akan memuaskan... Saya lebih suka default ke target yang dipilih pengembang daripada default ke semua target, tapi saya akan menerima salah satu solusi

Tidak apa-apa.

@shykes @drewcrawford :+1:

Semua yang akan terjadi adalah buruh pelabuhan akan menjadi cc baru, yang dipanggil orang dengan make.

Usulan dalam masalah ini sebenarnya adalah langkah yang agak sederhana di sepanjang garis itu: ia mengatakan "Kami membutuhkan yang setara untuk membuat target". Pertanyaan "versi make apa" tidak benar-benar masuk ke dalam gambaran--konsep "target" umum dibuat, Maven, rake, dan setiap sistem build serius lainnya. Mereka memiliki sintaks yang berbeda tetapi fakta bahwa fitur itu sendiri bersifat universal harus menjadi petunjuk bahwa ini adalah hal yang sering dilakukan orang ketika mereka membangun sesuatu.

@drewcrawford :+1: +1,000,000

Inilah situasi yang terus saya hadapi:

Saya ingin membuat dua wadah Docker dari repo saya. Mungkin salah satu server, salah satu database. Atau mungkin satu server dan yang lainnya adalah klien yang menjalankan tes otomatis terhadap server melalui panggilan API.

Bagaimanapun, ada beberapa file dalam repo yang perlu saya TAMBAHKAN untuk kedua wadah ini. Apa adanya, tidak mungkin melakukan ini tanpa harus menyalin Dockerfiles terpisah satu per satu dalam skrip bash, melakukan build, lalu mengganti atau menghapus Dockerfile.

Saya membutuhkan:

1. Perintah -f untuk menentukan file yang akan digunakan sebagai Dockerfile.
2. Kemampuan untuk MENAMBAH file bukan down-path dari Dockerfile.

Karena sudah berulang kali dikatakan bahwa nomor satu adalah larangan, dan saya menganggap nomor dua bahkan lebih sulit secara teknis, apa cara "tepat" untuk melakukan ini?

@ShawnMilo

@shykes komentar terakhir tampaknya menunjukkan ini tidak lagi pantas seperti dulu, tapi saya pikir kami masih belum jelas proposal mana yang sesuai atau apa yang perlu diubah jika tidak ada.

@jakehow Terima kasih atas pembaruannya. Jadi tampaknya perbaikan resmi untuk masalah ini masih jauh. Sementara itu, apakah ada "cara yang baik" untuk melakukannya? Ide terbaik yang saya miliki adalah skrip bash yang menyalin file satu per satu ke "Dockerfile" di root repo dan membuat gambar. Ini akan bekerja tetapi rasanya kotor.

@ShawnMilo ya saya pikir kebanyakan orang menggunakan alat build (make, rake, dll) atau sekadar skrip bash lama untuk melakukan ini.

Di atas seseorang menunjukkan cuplikan di mana mereka memiliki gambar pembuat yang menangani hal ini juga.

Inilah cara saya menangani masalah ini. Saya harus membuat gambar untuk berbagai versi platform, katakanlah v2 dan v3. Jadi saya punya Dockerfile.v2 dan Dockerfile.v3 Ketika saya ingin membuat build saya jalankan dulu ln -s ./Dockerfile.v3 ./Dockerfile lalu docker build . Sebenarnya saya punya skrip dan saya hanya menjalankan ./build v3 atau ./build v2

Saat ini saya menggunakan skrip yang menautkan Dockerfile tertentu ke ./Dockerfile , ini akan menjadi fitur yang bagus.

Saya membuat PR #7995 untuk mencoba mengatasi ini. Beberapa solusi yang dibahas dalam utas (panjang :-)) ini tampaknya sangat menyakitkan bagi orang untuk digunakan. Salah satu nilai jual terbesar Docker (bagi saya) adalah betapa mudahnya menggunakannya dan meminta orang untuk melompati rintangan semacam ini untuk apa yang terasa seperti permintaan yang cukup mudah rasanya tidak benar.

Sekarang, mungkin saya melewatkan sesuatu, tetapi apakah ada alasan teknis mengapa itu harus dinamai "Dockerfile"? Saat membuat PR, saya tidak dapat menemukannya dan saya terkejut melihat betapa mudahnya mengubahnya.

@duglin Anda memiliki semua dukungan saya.

Inilah yang kami lakukan untuk mengatasi kekurangan opsi -f dalam proyek kami saat ini.

# build.sh
...
mv specialDockerfile Dockerfile
docker build -t $(PROJECT) .

Anggap ini +1 untuk menambahkan -f .

Saat ini saya juga mengelola hal-hal seperti kikito. Saya menulis beberapa skrip Shell untuk membuat gambar yang berbeda dari konteks yang sama tetapi ingin melihat cara untuk menentukan file buruh pelabuhan dari argumen CLI seperti yang sudah disarankan. +1 untuk permintaan ini.

+1000

Saya menemukan ini hari ini ketika mencoba membangun proyek lintas platform golang menggunakan buruh pelabuhan. Ini berfungsi, lihat boot2docker , tetapi saya memerlukan Makefile untuk menyatukan bagian dalam dan luar proses pembuatan buruh pelabuhan, misalnya docker cp artefak dari buruh pelabuhan di dalam ke direktori pembangunan saya.

Namun jika saya mencoba menggunakan ini di subdirektori repo saya GOPATH rusak, karena folder .git di root repo hilang. Saya perlu ADD root repo dan kemudian membangun di dalam subdirektori saya, tetapi ini tidak diizinkan oleh buruh pelabuhan.

Setelah membaca utas panjang ini, saya melihat kekhawatiran tentang tidak dapat mereproduksi build. Salah satu cara untuk menguranginya adalah dengan hanya mengizinkan opsi -f menunjuk ke dalam konteks build atau ke bawah. Dengan cara ini Anda dapat memiliki banyak file Docker di subdirektori dan membangunnya dari root repo. Selain itu, Anda dapat membatasi ini agar berada dalam batas repo, misalnya pada level yang sama dengan .git/.hg/.foo dan di bawahnya tetapi tidak di luar repo.

Inilah yang saya pikirkan

FROM scratch
BUILD myname1 path/to/dockerfile/in/context
BUILD myname2 path/to/dockerfile2/in/context

docker build -t myimage .

Ini akan menghasilkan 3 gambar:

1. Gambar utama yang disebut "myimage", yang sebenarnya tidak memiliki apa pun di dalamnya sebagai contoh
2. Gambar bernama myimage-myname1
3. Sebuah gambar yang disebut myimage-myname2

Kata kunci BUILD akan mengambil nama dan jalur ke Dockerfile. Dockerfile ini harus berada dalam konteks aslinya.
Setiap instruksi build akan memiliki akses ke konteks penuh dari build utama.
Meskipun mungkin bermanfaat untuk membatasi konteks ke dir-tree yang berisi Dockerfile.

-1

Anda dapat menggunakan pengumpan konteks untuk docker build - seperti dockerfeed untuk kasus khusus ini.

@itsafire Intinya adalah membawa fungsionalitas jenis ini ke Docker sehingga ini bisa menjadi cara yang didukung untuk membangun proyek Anda. Saya yakin orang akan senang jika ini berfungsi dengan build otomatis juga.

Saya rugi di sini. Kami memiliki beberapa permintaan tarik untuk fitur tambahan ini, bukan? Dan itu tidak terlihat sulit untuk dilakukan ... Seseorang bahkan dapat menegakkan aturan yang disebutkan @maxnordlund : untuk membatasi jalur agar relatif terhadap konteks/root. Itu setidaknya akan membuatnya bekerja lebih lancar dengan boot2docket dan semacamnya, dan membuatnya "portabel".

Ini adalah celah yang paling menjengkelkan di Docker, dan karena semakin banyak alat mulai menggunakan Docker sebagai bagian dari fungsinya, penting bagi kita untuk segera menambahkan kemampuan untuk flag '-f' sehingga alat tersebut siap untuk digunakan. bahwa sebelum menjadi terlalu final... Terkait: memiliki Dockerfile multi-gambar tidak memotongnya, karena alat "meta" terkait ini sering mengasumsikan _one_ gambar per Dockerfile! Juga, menggunakan '-' tidak memotongnya dengan alat ini, dan sangat membatasi fungsinya, seperti yang kita semua tahu.

Dapatkah seseorang yang berwenang menjelaskan mengapa perbaikan ini belum digabungkan, atau setidaknya mengapa fitur yang sangat kurang ini masih belum ada?

Mulai terasa seperti Twilight Zone.

Saya kira ada ketidakcocokan dalam cara tim Docker menggunakan Docker / ingin Docker digunakan dan bagaimana sebagian besar komunitas menggunakan Docker. Koreksi saya jika saya salah.

Tim buruh pelabuhan ingin membangun repositori perangkat lunak yang tidak jauh berbeda dengan repositori proyek Debian. Dimana orang bisa mendapatkan software favorit mereka dan menjalankannya dengan mudah. Proses pembuatan untuk perangkat lunak harus dapat diulang dan jelas.

Yang lain ingin mengotomatiskan penyebaran perangkat lunak internal mereka yang sudah ada, yang sudah bisa sangat kompleks dengan banyak alat pembangunan, sistem CI, dll. Bagi mereka, Docker hanyalah alat lain yang harus sesuai dengan infrastruktur mereka. Dan mereka membutuhkan sedikit lebih banyak fleksibilitas dalam cara menggunakan Docker.

Saya pikir Docker (seperti .deb) dapat memenuhi kebutuhan kedua belah pihak, tetapi kompromi harus dilakukan.

Masalah dasarnya adalah: di mana ini berakhir? Turing kelengkapan untuk Dockerfile ? Mungkin tidak. Akan selalu ada kebutuhan akan lebih banyak fleksibilitas untuk menyelesaikan kasus khusus. Beberapa ide akan memasuki bahasa Dockerfile, yang lain tidak. Karena buruh pelabuhan dapat memakan konteks melalui stdin pada build, fungsionalitas yang hilang dapat diimplementasikan melalui pra-prosesor.

@itsafire Terakhir kali saya memeriksa, buruh pelabuhan dapat memakan Dockerfile tetapi bukan konteks. Faktanya, konteksnya diabaikan ketika Anda menyediakan Dockerfile dengan cara itu. Jika mereka menambahkan dukungan untuk apa yang Anda sarankan, ini akan menjadi masalah tertutup.

Saya belum melihat beberapa saat tetapi permintaan dasarnya adalah ini: beri kami cara eksplisit untuk menyediakan Dockerfile DAN context selama pembuatan. Jujur kaget ini seperti 8 bulan kemudian dan masih buka.

@thedeeno ini memang mungkin
cat mystuff.tar.gz | docker build -

@ cpuguy83 tapi saya tidak bisa menyediakan Dockerfile eksplisit dengan perintah itu. Benar?

@thedeeno ya, Anda memasang Dockerfile apa pun yang Anda inginkan dengan konteks apa pun yang Anda inginkan.

@cpuguy83 @thedeeno Tidak, itu tidak berhasil, karena Anda kemudian tidak dapat MENAMBAHKAN file apa pun karena tidak ada dalam lingkup "cwd" yang biasanya Anda dapatkan dengan Dockerfile.

Sunting: Pernyataan ini salah; Saya salah memahami contoh @ cpuguy83 .

@ShawnMilo ya itu. Apa pun di tar berada dalam konteks.

@cpuguy83 Maaf, kesalahan saya. Saya buru-buru membacanya hanya sebagai pemipaan di Dockerfile, bukan seluruh tarball.

@cpuguy83 Bagus! Saya memilih tutup jika itu berfungsi seperti yang Anda sarankan.

Pertanyaan sampingan, dalam stempel waktu solusi khusus saya merusak cache saat taring. Itu masih menjadi masalah? Jika saya tar folder yang sama beberapa kali, apakah itu akan menggunakan cache saat dibangun?

Pertahankan pekerjaan hebat!

Pemipaan seluruh konteks tidak meringankan apa yang kita bicarakan di atas, sama sekali.

Yang kami inginkan dan butuhkan adalah cara menggunakan konteks _same_ dengan berbagai file Docker. Seperti "build with logging" dan "build without logging" yang disebutkan di atas, sebagai gambar individual. Saya memiliki banyak kasus penggunaan lain di mana ini diperlukan.

Saya gagal melihat bagaimana tar-balling direktori akan membantu dalam hal ini. Ya, seseorang dapat membuat direktori khusus dan menyalin Dockerfile tertentu di sana, dan kemudian seluruh direktori konteks, atau tar dan menambahkan Dockerfile baru, lalu gzipping. Tetapi bagaimana itu lebih mudah daripada solusi [sangat mengerikan] yang saat ini harus kita terapkan untuk memiliki skrip pra-prosesor yang menempatkan Dockerfile yang benar sebelum menjalankan buruh pelabuhan?

Dan, ini tidak akan membantu ekologi Docker, seperti yang saya sebutkan di atas.

Apakah saya melewatkan sesuatu?

Sekali lagi, opsi '-f' sederhana. Tolong. Tolong, cantik tolong. Paksa itu menjadi jalur relatif dari konteksnya. Ini baik saja.

@davber Yang Anda inginkan adalah agar Docker menangani tarballing konteks dan Dockerfile untuk Anda.
Dan saya tidak sepenuhnya menentang ini. Meskipun saya pikir build bersarang mungkin merupakan solusi yang lebih baik untuk ini.

@ cpuguy83 : ya, jadi saya ingin Docker menanganinya untuk saya, ya, yang termasuk memilih bagian konteks dari satu tempat dan Dockerfile dari kemungkinan tempat lain, atau dengan nama yang tidak standar. Yaitu, untuk mendukung bendera '-f' yang terpisah :-)

Pembuatan bersarang tidak menyelesaikan masalah yang kami hadapi, yang memulai utas ini, dan mempertahankannya.

Yaitu, kami masih ingin menggunakan konteks root yang sama.

Ya, kami dapat menyalin file, dan, ya, kami melakukannya untuk menghindari ini bagi kami kopling aneh konteks dengan Dockerfile yang tepat bernama 'Dockerfile'. Tapi itu tidak ideal, dan menyiapkan rsync untuk memastikan file memang identik dengan yang asli hanya aneh.

@cpuguy83 : dapatkah Anda menjelaskan bagaimana build bersarang akan membantu saya, atau "pengeluh" lainnya di sini? :-)

@davber
Pendapat saya adalah ini:

FROM scratch
BUILD myname1 path/to/dockerfile
BUILD myname2 path/to/another/dockerfile

Dan ini:

docker build -t myimage .

Akan menghasilkan 3 gambar, "myimage", "myimage-myname1", "myimage-myname2".
Setiap build dalam akan memiliki akses ke konteks build lengkap sebagai jalur absolut. Jalur relatif akan relatif terhadap Dockerfile.
Dan "myimage" bisa memiliki barangnya sendiri selain instruksi BUILD.

Seperti yang saya sebutkan sebelumnya, banyak alat baru dalam ekologi Docker yang lebih besar (dan hebat!) mengasumsikan bahwa setiap Dockerfile dikaitkan dengan tepat satu gambar Docker. Berbagai alat orkestra mirip "Gambar" di luar sana. Dan banyak solusi cloud baru dan lama yang memiliki dukungan khusus untuk Docker juga memiliki asumsi satu-ke-satu ini. Memang, mereka di dunia yang dibuat oleh opsi '-f' kemudian tidak hanya harus mendapatkan konteks -- sebagai bola tar misalnya -- tetapi juga, berpotensi terpisah, Dockerfile. Tetapi setiap unggahan tersebut masih akan sesuai dengan tepat satu gambar Docker.

Jika kita menggunakan rute yang berpotensi memisahkan Dockerfile dari root konteks, saya harap alat ini akan mulai hidup dengan skenario ini:

Each deployment/use of a Docker image is done with an upload of either:

   1. a Dockerfile solely, when no contextual operations are needed
   2. a context tar ball only, containing the context with a top-level Dockerfile
   3. both a context tar ball and a separate Dockerfile

Semakin lama kita bertahan dengan penggabungan kuat 'Dockerfile' di tingkat atas konteks, semakin mengakar dalam ekologi. Yaitu, kita harus bertindak sekarang, karena dunia Docker bergerak dengan cepat, karena kedahsyatannya secara umum.

Dan, sejujurnya, itu adalah asumsi yang masuk akal dan menarik secara konseptual, untuk memiliki isomorfisme antara Dockerfiles dan gambar, meskipun yang pertama akan benar-benar menjadi ruang produk direktori konteks (tared up ...) dan Dockerfiles, default ke (null, file) jika hanya Dockerfile yang disediakan dan (konteks, konteks/'Dockerfile') jika hanya konteks yang disediakan.

Dan bahkan untuk penerapan lokal: katakan bahwa kami ingin menggunakan Fig setidaknya untuk orkestrasi lokal: bagaimana cara melakukannya? Apa yang harus dilakukan adalah membuat gambar sebelumnya dari Dockerfile multi-build, dan kemudian merujuk ke gambar tersebut pada Gambar. Tidak optimal.

isomorfisme antara Dockerfiles dan gambar

Asumsi ini sudah rusak dalam bagaimana orang-orang di utas ini menggunakan Dockerfiles. Yaitu menggunakan scripting untuk mengganti Dockerfile secara manual sebelum menjalankan docker build. Mereka mungkin juga memiliki orkestrasi sendiri. Permintaan fitur ini bukan tentang mengubah lanskap buruh pelabuhan, ini tentang membuat buruh pelabuhan bekerja untuk jenis penggunaan tertentu.

@hanikesn : dua komentar:

1. mengapa asumsi itu rusak karena harus menyalin Dockerfiles ke tempatnya sebelum membangun; itu masih akan menjadi satu Dockerfile <-> satu gambar?
2. apa yang saya perdebatkan adalah bahwa saya ingin solusi apa pun yang kami buat di sini untuk _bekerja dengan_ lanskap Docker yang ada dan berkembang, tanpa perubahan yang terlalu besar yang diperlukan dalam lanskap ini; dan saya pikir dengan _menjaga_ isomorfisme yang disebutkan, kami melakukannya.

Saran lain di sini adalah memiliki satu Dockerfile multi-gambar, yang berpotensi memanggil sub-Dockerfiles. Itu tidak akan berfungsi dengan cara sebagian besar alat (Gbr. dll.) saat ini menggunakan Docker.

@davber

Pembuatan bersarang tidak menyelesaikan masalah yang kami hadapi, yang memulai utas ini, dan mempertahankannya.

Saya mengusulkan solusi ini yang sudah saya tunjukkan sebelumnya:

$ docker-pre-processor [ --options ... ] . | docker build -

Sedangkan --options adalah aturan konteks dalam direktori (di sini) saat ini harus diubah dan diteruskan ke buruh pelabuhan. Ini harus dilakukan dengan cepat dengan membuat arsip tar sementara yang berisi konteksnya. Dengan begitu konteks sumber dapat tetap tidak tersentuh. Lebih mudah untuk mengubah pra-prosesor daripada sintaks Dockerfile.

@itsafire

Bagaimana dengan alat yang mengharapkan Dockerfiles hari ini? Mereka menjadi lebih banyak, menggunakan Amazon, Google, atau semacamnya. Dan Fig dan kerangka orkestrasi serupa.

Kami kemudian harus mendorong alat 'pra-pemroses buruh pelabuhan' standar dan penggunaan alat tersebut ke kerangka kerja, penyedia, dan alat tersebut.

Pasti akan jauh lebih mudah memiliki 'docker' dukungan yang tepat setidaknya opsi yang memicu utas ini.

@itsafire semua orang dengan masalah ini yang telah menyelesaikannya sudah menggunakan semacam preprocessor atau pembungkus di sekitar docker build untuk mencapai tujuan ini.

Fragmentasi di sekitar situasi ini bertentangan dengan tujuan 'pengulangan' yang dinyatakan oleh tim @docker . Diskusi ini dan yang lainnya adalah tentang menyelesaikan masalah ini.

1+ tahun dan 130+ komentar dan terus bertambah untuk masalah sederhana yang memengaruhi sebagian besar pengguna... Saya terkesan. Teruslah bekerja dengan baik, Docker!

+1

Alat harus membantu orang untuk mengikuti cara mereka sendiri, tetapi tidak memaksakan cara yang "benar". Kasus sederhana yang membawa saya ke diskusi ini:

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

Cara saya adalah menjaga root proyek tetap bersih. Tetapi ADD ../src dan -f deploy/Dockerfile tidak berfungsi. Untuk saat ini saya memiliki Dockerfile dan .dockerignore di root proyek, tetapi itu menyakitkan bagi saya.

Di pihak saya, saya telah membuat skrip yang menyiapkan folder dengan file yang diperlukan dan menjalankan baris perintah standar docker build -t my/image . karena saya mengalami masalah bahwa file .dockerignore diabaikan oleh ADD ...

+1 yakin ingin dapat memiliki banyak file Docker dalam satu repo. Kasus penggunaan saya: Satu gambar untuk penggunaan dan penyebaran produksi, gambar lain adalah contoh pelaporan yang dirancang untuk menggunakan alat backend dan konektivitas database yang sama, tetapi tidak memerlukan pengawasan front-end, web, layanan sistem, atau proses...

+1 untuk ini. Saya perlu menambahkan file ke gambar yang berbeda dari folder yang sama, untuk server yang berbeda.

+1 Saya menikmati Docker sejauh ini, tetapi karena cara mereka mengatur tim saya, saya benar-benar membutuhkan cara untuk membangun berbagai penerapan yang berbagi potongan kode yang baik, dari satu repo. Tidak terlalu tertarik untuk membangun semuanya menjadi wadah uberdocker karena siklus penyebaran/pelepasan mereka diikat secara tidak perlu. Apa praktik terbaik untuk mengatasi ini?

@jfgreen : Letakkan beberapa Dockerfiles di mana pun Anda suka, dan beri nama apa pun yang Anda suka. Kemudian buat skrip bash yang menyalinnya satu per satu ke root repo sebagai "./Dockerfile," menjalankan "docker build," lalu menghapusnya. Itulah yang saya lakukan untuk banyak proyek dan itu bekerja dengan sempurna. Saya memiliki folder "dockerfiles" yang berisi file-file bernama hal-hal seperti database, base, tes, dll yang semuanya Dockerfiles.

@ShawnMilo Terima kasih, itu sepertinya solusi yang sangat masuk akal.

+1

+1

+1 ke -f . Ada default waras yang jika bendera dihilangkan, Docker akan melakukan _hal yang benar._ Dalam hal karena alasan apa pun tampilan yang sangat spesifik dari _hal yang benar_ adalah untuk pengguna _hal yang salah_ ada -f . Perbandingan alat seperti make menurut saya masuk akal. make juga merupakan utilitas yang sangat berpendirian yang awalnya ditulis pada tahun 1976 dan karena itu memiliki cukup waktu untuk menstabilkan serangkaian fitur. Saya pikir ini instruktif bahwa dalam man make satu-satunya flag yang disebutkan dalam sinopsis yang sangat singkat adalah... -f .

       make [ -f makefile ] [ options ] ... [ targets ] ...

Tidak ada masalah dalam utilitas berbasis ux yang berpendirian, tetapi beberapa hal seperti -f adalah anggukan pragmatis untuk pengguna di dunia nyata. Sebuah alat seharusnya membuat hidup Anda lebih mudah bukan lebih sulit. Jika saya harus menulis Makefile atau skrip shell untuk bekerja di sekitar alat tanpa -f adalah kegagalan alat. Jelas dari jumlah pengguna yang telah meluangkan waktu untuk berkomentar dan mempertimbangkan +1, fitur ini memiliki utilitas yang signifikan bahkan setahun setelah pertama kali diusulkan.

+1

+1 (atau posting blog resmi dengan solusi yang disarankan)

+1

+1

@crosbymichael Saya percaya ini bisa ditutup sekarang karena #9707 sedang digabung

KEMENANGAN.

Jika Anda semua ingin mencoba fitur baru ini, Anda dapat mengunduh binari untuk master di:

master.dockerproject.com

Terima kasih @duglin !

:tepuk:

Terima kasih @crosbymichael untuk binernya! :+1:

Bagus sekali! :tepuk:

Jadi docker build -f Dockerfile.dev . ? edit: ya