Compose: docker-compose up tidak menarik gambar terbaru jika gambar ada secara lokal

Apakah ada alasan mengapa docker-compose pull && docker-compose up tidak praktis?

Saya pikir sebagian besar poin untuk/melawan sama dengan yang dibahas dalam masalah untuk menambahkan --pull ke docker run . Mulai dari ux dan konsistensi, hingga kemudahan skrip/alur kerja, hingga integrasi swarm (karena penasaran, apa yang dilakukan docker-compose pull dengan swarm?).
Saya tidak berpikir itu masalah besar, tetapi sesuatu yang perlu dipertimbangkan. Jenis pengguna yang sama yang menginginkan fitur di tempat lain kemungkinan juga akan menikmatinya di sini.

Saya mencoba menjalankan "docker-compose build", tetapi itu tidak menyegarkan gambar yang dirujuk di Dockerfile, kecuali ketika Anda menggunakan _--pull_.

Anda juga dapat membangun wadah selama awal dengan _up --build_. Tapi gambar terbaru tidak akan ditarik. Bisakah kita mengharapkan sthg seperti "docker-compose up --build --pull" (atau serupa)? Mungkin masuk akal untuk menempatkannya di YML karena tidak semua build harus di-refresh (lihat gambar lokal).

Alih-alih (atau sebagai tambahan) menambahkan --pull ke cli, bagaimana dengan menambahkan sesuatu pada definisi layanan di file docker-compose?, misalnya

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

Dengan cara ini jika ada layanan yang saya tidak peduli tentang menjadi yang terbaru dan yang saya lakukan, docker-compose tidak akan membuang waktu mengunduh gambar yang tidak saya minati

Saya datang ke sini untuk mencari fitur ini karena kami menggunakannya di kluster produksi Kubernetes kami. Di sana tagnya adalah "imagePullPolicy" dan dapat disetel ke "IfNotPresent", "Always", atau "Never." Sesuatu yang serupa untuk lingkungan penulisan akan menyenangkan.

Dalam kasus kami, kami perlu membangun kembali gambar dasar setiap hari untuk memastikan dependensi terbaru diperbarui untuk aplikasi. Komposisi Docker untuk menarik gambar terbaru dengan tag yang sama adalah fitur yang bagus. Mengapa tidak !

Ada berita tentang ini?

Hai,

Ada berita tentang masalah ini?

+1

+1

Seperti yang saya sebutkan sebelumnya, docker-compose pull && docker-compose up secara fungsional identik. Tidak ada alasan bagus untuk menambahkan bendera lain untuk itu.

Bayangkan bahwa git tidak memiliki pull karena git fetch && git merge origin/master secara fungsional identik.

Menambahkan tag pull: true dapat berguna misalnya jika beberapa gambar yang Anda gunakan dalam file penulisan ada di cache Anda. docker-compose pull tarik _semua_ gambar di file penulisan Anda, dan tarikan itu akan gagal jika gambar-gambar ini ada di cache Anda tetapi tidak di repositori.

+1

Salah satu skenario di mana docker-compose pull && docker-compose up menjadi tidak praktis adalah ketika Anda menggunakan beberapa file pembuatan buruh pelabuhan. Anda dapat dengan mudah berakhir dengan perintah seperti docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up .

Kami memiliki skenario di mana kami mengembangkan secara lokal dan kami hanya ingin menarik beberapa gambar dari jarak jauh. Satu (atau lebih) yang dikembangkan secara lokal harus tetap tidak tersentuh. Dalam hal ini kita diwajibkan untuk membuat/menarik image secara manual sebelum menjalankan docker-compose up.
pull: true akan bermanfaat.

@shin- bagaimana dengan memikirkan kembali keputusan Anda tentang ini? Saya percaya komentar dan reaksi terhadap mereka terlihat cukup menggambarkan diri sendiri.

Tidak, aku baik-baik saja. Ini adalah proyek sumber terbuka, jika Anda tidak setuju dengan pendekatan konservatif yang kami ambil saat menambahkan fitur, Anda dipersilakan untuk menggantinya.

Setuju untuk menambahkan flag ke perintah docker-compose up atau parameter ke konfigurasi. Kami menggunakan gambar dasar dengan konfigurasi tambahan yang cenderung sering berubah selama proses pengembangan. Kami ingin membuat lingkungan yang sangat mudah, di mana pengembang dapat dengan mudah menjalankan docker-compose up tanpa men-debug apa yang tidak perlu mereka debug.

Saya benar-benar membuka utas ini setelah rekan saya memeriksa permintaan tarik saya dan mengatakan itu merusak build. Dan alasannya adalah bahwa gambar dasar hanya kehilangan beberapa paket - tetapi dieksekusi di Dockerfile terakhir. Itu akan menjadi fitur yang bagus, tetapi tampaknya bukan sesuatu yang Anda gunakan, @shin- .

Kami akan senang jika Anda memperkenalkan fitur ini di versi baru.

@shin- Saya pikir @blockloop menunjukkan dengan contoh git betapa nyaman/bergunanya opsi tarik. Sejujurnya saya berharap untuk hal-hal seperti itu tidak perlu memotong proyek apa pun.

Saya benar-benar mengerti pendekatan konservatif tetapi rasanya itu bahkan tidak dianggap sebagai pilihan lagi. Mungkin itu bisa menjadi bagian dari versi yang akan datang?

pull: IfNotPresent akan menyenangkan. Jadi mungkin saja menggunakan fallback seperti
1) gunakan gambar lokal
2) tarik jika bukan lokal
3) membangun jika tidak mampu menarik

@shin- Anda terus menanyakan alasan mengapa metode && tidak memotongnya, dan alasan saya adalah ini. Saya menggunakannya untuk gambar "aplikasi" untuk pengujian (PDK Wayang/Sekali Lagi). File penulisan adalah bagian dari repo templat sehingga ketika seorang pengembang boneka (benar-benar ops people) perlu membuat modul baru, mereka memotong repo itu. Jenkins menjalankan gambar untuk validasi gabungan pada repo modul itu (secara internal kami memiliki plugin jenkins yang menangani pembaruan untuk pekerjaan tersebut.) Sekarang orang-orang yang menggunakan ini tidak akan menjadi ahli buruh pelabuhan, dan harus memberi tahu mereka untuk melakukan && adalah tambahan langkah yang mereka dapat (dan mungkin akan) mengacaukan. Saya tidak melihat mengapa itu akan sulit atau kerugian apa yang akan ditimbulkannya tetapi alasan ini sepertinya merupakan alasan yang berharga untuk menambahkannya. Ini membantu kami para pengembang mengirimkan hal-hal yang membutuhkan lebih sedikit petunjuk dan langkah..

singkatnya adalah .... untuk melindungi dari kemalasan

Inilah alasan yang lebih baik: && sinkron. Tetapi docker-compose telah membangun dukungan besar untuk pelaksana paralel yang mengoptimalkan hal ini. docker-compose up --pull --build dapat mulai membangun image dan menjalankannya segera setelah ditarik, daripada menunggu semua gambar ditarik dan baru kemudian mulai membangun

@shin mengasumsikan seseorang menggunakan untuk diri kita sendiri dengan sangat jarang dengan memperbarui Dockerfiles yang jarang.
Tetapi jika Anda memperbarui gambar Docker setiap hari yang akan digunakan pengembang, itu akan dengan cepat menyebabkan masalah pengembangan jika hanya satu pengembang lupa untuk menarik gambar yang harus dia lakukan setiap hari (terutama mereka yang tidak terlalu akrab dengan buruh pelabuhan, dan itu sebenarnya bukan urusan mereka untuk mengetahui dan mengingatnya). Bencana terprogram.
Apakah masalah besar hanya menambahkan opsi ini ke docker-compose.yml ?
Maksud saya, itu tidak akan mengubah hal-hal lain, itu hanya menambah fungsionalitas. ..

itu adalah alasan pembunuh mengapa saya tidak bisa menggunakan docker-compose dan perlu menulis skrip pembungkus dengan perintah run docker lawas, tapi itu jelek.

Mencoba mencari tahu keadaan di mana tiket ini ditutup - bisakah seseorang menjelaskannya? Jika ada bantuan, saya pro menambahkan flag --pull ke docker-compose up .

Saya pikir ada dua proposal yang dibahas di sini:

1 - Haruskah ini ditambahkan sebagai opsi baris perintah? Sebenarnya masalah diposting.
2 - Haruskah opsi ini ditambahkan ke file YML.

Saya sangat setuju dengan yang terakhir, meskipun @shin sebenarnya tidak mengomentari itu. Untuk mengabaikannya dengan argumen yang sama, bahwa itu identik secara fungsional akan menjadi tidak koheren. Semua yang ada di file YML secara fungsional identik dengan baris perintah.

Saya dapat melihat maksudnya sehubungan dengan yang pertama, tetapi saya pikir alasannya agak terlalu luas. Saya dapat melakukan apa saja di baris perintah dengan menyatukan serangkaian pernyataan dengan && . Mari kita perjelas, itu adalah dua perintah, bukan satu. Kriterianya harus: Apakah ada cukup permintaan untuk ini sehingga memungkinkan untuk melakukannya dalam satu langkah, bukan dua? Karena jika digunakan cukup sering, perintah nomor berantai terus bertambah. Intinya, ketika Anda menulis naskah, Anda menginginkannya sesingkat mungkin.

@orodbhen tidak perlu berdebat. Tidak ada yang mendengarkan kita di sini.

Untuk menambah alasan untuk menambahkan bendera ... selama setahun terakhir ini saya menemukan diri saya mencari hal ini dan berakhir di sini hanya untuk menemukan bahwa saya telah mengacungkan beberapa komentar yang mendukung a --pull bendera. Saya membayangkan saya akan menemukan diri saya lagi di sini lain kali juga.

@shin-, tolong buka kembali atau kunci masalah ini. Sudah terbuka selama hampir dua tahun, menerima komentar konstan (baik cerdas dan menghibur), puluhan peserta, dan ratusan suara.
Namun, tampaknya tim penyusun tidak tertarik untuk mengejar fitur ini. Jadi jangan buang waktu siapa pun atau memberi ruang untuk harapan palsu bahwa masalah ini akan dihidupkan kembali jika bukan itu masalahnya.

Harap menahan diri dari menggunakan kata-kata kotor.

Sementara saya pikir ada kegunaan dalam permintaan yang asli, banyak orang di thread ini tampaknya melupakan semangat open source: jika itu yang penting bagi Anda, Anda bebas untuk garpu dan memodifikasi untuk isi hati Anda. Saya mengerti bahwa Anda mungkin tidak ingin mempertahankan garpu, tetapi mengeluh bahwa pengelola tidak akan mengimplementasikan fitur adalah kontra-produktif: bukan itu cara penerapan fitur, dan akan membuat pengelola tidak ingin membantu Anda lebih sedikit .

Tidak masalah jika ada permintaan untuk suatu fitur, terutama jika tidak ada yang membayar untuk menggunakan produk tersebut. Ada lebih banyak hal yang perlu dipertimbangkan daripada sekadar memasukkan setiap fitur yang diinginkan semua orang ke dalam produk utama. Kita harus menghormati tanggapan @shin- tentang ini, dan percaya ada alasan bagus untuk tidak menerapkannya.

@lig Tidak ingin berdebat. Hanya membuat kasus.

Tergantung pada kebutuhan Anda, forking mungkin berlebihan. Dalam kasus khusus saya, saya menemukan Compose tidak cocok untuk skrip, kecuali skrip yang sangat mendasar. Menggunakan Docker Python API dan dan file YAML saya sendiri untuk mempertahankan pengaturan lebih fleksibel dan seringkali lebih sederhana.

@ bdharington7 — tetapi Anda harus memelihara garpu Anda dan tetap memasangnya di semua mesin yang Anda gunakan (hal yang jarang terjadi). Peringatan apakah Docker Compose populer, yang lain akan berkata: siapa yang peduli?

Kenyataannya adalah bahwa komentar "ini open source, buat garpu Anda sendiri", tidak realistis. Biaya pemeliharaan fork Anda sendiri dan selalu up to date dengan perubahan terbaru dari repositori utama membuatnya jarang bernilai investasi. Pendekatan yang jauh lebih baik adalah mengajukan petisi kepada pengelola dan memberikan alasan yang tepat mengapa fitur itu penting.

Sayangnya itu akan selalu menghasilkan masalah seperti ini dengan beberapa ketidakpuasan. Saya pikir masalah utama di sini adalah bahwa tampaknya tidak ada kasus yang tepat yang diajukan mengapa ini adalah ide yang buruk. Argumen

"Kita harus menghormati tanggapan @shin- tentang ini, dan percaya ada alasan bagus untuk tidak menerapkannya."

hanya tidak akan memuaskan orang. Masyarakat perlu melihat “alasan yang baik”.

Intinya tetap bahwa mengepalkan tinju dan memohon jarang akan menghasilkan
dalam mendapatkan apa yang Anda inginkan, banyak yang terjadi di utas ini.
Ada banyak kasus penggunaan bagus yang diangkat di utas juga,
tetapi kecuali Anda benar-benar membayar untuk perangkat lunaknya, tidak ada kewajiban
dari pengelola untuk melakukan sesuatu tentang hal itu, atau memberikan alasan mengapa. saya
hanya memberi @shin- dan perusahaan manfaat dari keraguan di sini.
Pada Sabtu, 24 Maret 2018 pukul 5:39 pagi, Greg Pakes [email protected] menulis:

Kenyataannya adalah bahwa komentar "ini open source, buat garpu Anda sendiri",
hanya tidak realistis. Biaya pemeliharaan garpu Anda sendiri dan
tetap perbarui dengan perubahan terbaru dari repositori utama
membuatnya jarang bernilai investasi. Pendekatan yang jauh lebih baik adalah dengan mengajukan petisi
pengelola dan memberikan alasan yang tepat mengapa fitur tersebut
penting.

Sayangnya itu akan selalu menghasilkan masalah seperti ini dengan beberapa orang
ketidakpuasan. Saya pikir masalah utama di sini adalah sepertinya tidak ada
telah menjadi kasus yang tepat dikemukakan mengapa ini adalah ide yang buruk. NS
argumen "Kita harus menghormati tanggapan @shin- http:///shin- tentang ini,
dan percaya ada alasan bagus untuk tidak menerapkannya."
akan memuaskan orang. Masyarakat perlu melihat “alasan yang baik”.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

Intinya tetap bahwa mengepalkan tangan dan memohon jarang akan menghasilkan apa yang Anda inginkan

Ini tidak benar. Meskipun saya tidak membenarkannya sebagai strategi untuk meminta pekerjaan gratis dilakukan, sebenarnya ini cukup efektif. Ini persis bagaimana petisi bekerja dan semakin banyak orang yang "mengacungkan tinjunya" semakin besar kemungkinan orang yang peduli untuk memperhatikan. Sekali lagi, saya tidak mengatakan saya menyetujuinya

Ada banyak kasus penggunaan bagus yang diangkat di utas juga

Saya dapat melihat satu kasus, yang pada dasarnya bermuara pada "Anda dapat melakukan dua perintah ini sebagai gantinya". Tapi jelas orang tidak menginginkannya. Jadi libatkan mereka dan didik mereka mengapa ini adalah pekerjaan yang baik.

tidak ada kewajiban dari pengelola untuk melakukan apa pun, atau memberikan alasan apa pun

Saya setuju. Tetapi Anda harus mengharapkan orang-orang menjadi frustrasi dengan itu. Itu adalah sikap meremehkan. Pada akhirnya, semua orang di sini berada di tim yang sama. Orang-orang yang memelihara proyek dan pengguna proyek semuanya hanya ingin proyek itu berhasil.

Produk mana yang gratis tepatnya di sini? Jika saya menggunakan docker-compose.exe dan menjalankan docker EE, bukankah itu berarti bahwa saya sebenarnya membayar untuk produk?

IMHO --build harus menarik; tidak perlu flag atau konfigurasi lain. jika Anda tidak ingin menariknya, tentukan versi gambar.

@ET-CS: versi gambar hanyalah tag dan masih dapat diubah ke hash yang berbeda

poin bagus @lifeofguenter terima kasih. dapatkah menulis memeriksa apakah gambar diubah ke hash yang berbeda dan menarik kasing itu juga?

Dalam scenerio seperti itu, saya pikir saya ingin semua lingkungan (dev, prod) memiliki gambar yang sama seperti sekarang karena devs menggunakan hash baru sementara produksi menggunakan yang lebih lama.

Saya berharap --build membawa semuanya ke yang terbaru.

Jadi, inilah kasus penggunaan yang bagus:

Saya menerapkan CI untuk proyek layanan mikro saya, yang menarik gambar baru ke registri saat kami mengembangkan fitur baru di layanan backend. Tim frontend (yang tahu sedikit tentang buruh pelabuhan) perlu memiliki cara untuk memunculkan seluruh tumpukan backend di mesin lokal mereka, dan mereka mengandalkan gambar yang paling baru. Jika ada yang rusak, baru mereka akan ingat untuk menarik gambarnya.

Sekarang inilah yang terjadi: Seluruh sprint pengembangan gagal karena seseorang lupa memperbarui gambar backend, dan mengembangkan seluruh fitur berdasarkan versi lama. Salahkan tim frontend, tetapi ini dapat dihindari dengan fungsi ini (yang akan saya lakukan menggunakan skrip pembungkus).

@agnjunio Kedengarannya sangat disayangkan, maaf. Namun, jika orang tersebut lupa menjalankan docker-compose pull , saya tidak yakin bagaimana kemungkinan mereka lupa untuk menggunakan flag --pull hipotetis?

@shin- Maaf, saya lupa menyebutkan hal penting: Solusi dalam kasus saya adalah memiliki tag pull: always di dalam yaml, mungkin di dalam opsi image:

@ET-CS dari https://github.com/docker/compose/issues/3574#issuecomment -382451356:

Saya berharap --build membawa semuanya ke yang terbaru.

IMHO --build harus menarik; tidak perlu flag atau konfigurasi lain. jika Anda tidak ingin menariknya, tentukan versi gambar.

AFAIK yang akan memblokir use case dengan build menggunakan FROM yang merupakan hasil dari depends_on build.

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

Saya mendukung bendera seperti yang disarankan di https://github.com/docker/compose/issues/3574#issuecomment -252861859 dan https://github.com/docker/compose/issues/3574#issuecomment -279460839

@solsson
Saya tidak yakin saya mengerti mengapa atau apa yang diblokir dalam kasus penggunaan ini.
tolong bagikan lebih banyak informasi tentang itu jika Anda bisa.

@shin- Perbedaannya di sini adalah jika saya menjalankan docker-compose up --help Saya akan menerima cara deskriptif tentang cara menggunakan: gambar terbaru, alih-alih saat ini saya harus mencari di doc atau di google yang mengarahkan saya ke utas ini dan saya harus membaca semua komentar untuk memahami bahwa docker-compose up tidak melakukan apa yang saya butuhkan/inginkan, jadi sekarang saya perlu menjalankan dua perintah.

@agnjunio Kedengarannya sangat disayangkan, maaf. Namun, jika orang tersebut lupa menjalankan docker-compose pull, saya tidak yakin bagaimana mereka lupa menggunakan flag --pull hipotetis kemungkinannya lebih kecil?

dengan hormat

Salah satu alasan utama kami menggunakan docker-compose adalah kemampuan untuk menempatkan file docker-compose.yaml ke dalam repositori dan memiliki keluaran yang dapat direproduksi ketika pengembang menarik repositori dan menjalankan docker-compose up [service] .

Kami menggunakan beberapa layanan dalam file komposisi buruh pelabuhan kami yang melakukan tugas seperti menjalankan codegen dan menjalankan alat untuk mereferensikan skema JSON ke dalam satu file.
Memastikan alat-alat ini mutakhir sangat penting terutama jika kami memperbarui gambar codegen kami untuk memperbaiki beberapa masalah kritis umum yang terlihat di semua proyek.

Memiliki kemampuan untuk menempatkan:

services:
  codegen:
    image: myimage:latest
    pull: Always

akan mempertahankan kemampuan kami untuk memiliki pengembang yang andal menjalankan komposisi buruh pelabuhan dan mendapatkan hasil yang diharapkan, daripada harus melengkapi setiap repositori dengan dokumentasi untuk mengingatkan pengembang untuk menjalankan rantai perintah atau skrip untuk menarik gambar terbaru yang tersedia sebelum memulai aplikasi .

Ini bukan tentang "fungsi yang sudah ada untuk melakukan ini dengan menjalankan perintah ini", ini adalah pengalaman pengguna yang lebih baik.

Bayangkan ketika seseorang menyarankan untuk menambahkan --stop ke docker-compose rm bahwa jawabannya adalah "apa yang salah dengan docker-compose stop myapp && docker-compose rm myapp , atau jika seseorang telah meminta implementasi docker-compose down mereka hanya ditanya mengapa docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... tidak praktis?

Utas ini telah diangkat 2 tahun yang lalu dan saya masih berpikir bahwa menambahkan bendera di docker-compose.yml adalah cara terbaik. Dalam kasus saya, kami memiliki 37 layanan dalam segerombolan, dan memperbarui 4-5 gambar dari total itu tidak mudah. Saya baru saja membuat shell untuk saat ini yang dapat memantau perubahan dari repositori dan melakukan tarikan untuk gambar tertentu sebelum membuat ulang layanan jika telah diperbarui.

Poin lain di sini adalah bahwa docker-compose up memiliki opsi --quiet-pull . Ketika saya pertama kali mencoba mencari tahu apakah up termasuk tarikan, saya berasumsi itu berdasarkan kehadirannya. Masuk akal bahwa tidak menggunakan --quiet-pull menghasilkan tarikan verbose.

Dua tahun orang mencoba meyakinkan pengelola Docker Compose bahwa memiliki opsi --pull akan menjadi pengalaman yang lebih baik tanpa harus menjalankan perintah terpisah. Jika pengelola docker-compose baru saja mengimplementasikan fitur tersebut, untuk memulainya, kehidupan semua orang akan lebih baik. Tampaknya jelas bahwa pengelola saat ini tidak ingin menambahkan fitur ini untuk kemajuan komunitas.

Mungkin kita harus melakukan fork docker-compose dan memperbaruinya sendiri.

Jika seseorang mengajukan PR, apakah ada peluang jika diterima?
Ini adalah sumber terbuka. Saya sudah dekat untuk mengimplementasikannya beberapa
kali diriku. Saya berasumsi itu bisa diterima, jika tidak, peran ini ditutup,
Baik?

Saya mengalami masalah yang sama dan omong kosong suci ini, sekelompok pengeluh di sini. Ini adalah perangkat lunak sumber terbuka GRATIS. Beri pengelola istirahat. Saya yakin mereka memiliki hal-hal yang jauh lebih penting untuk dikerjakan daripada ini. Jika ada yang sangat membutuhkan ini, mengapa Anda tidak membuka PR? Jika kodenya bersih dengan risiko minimal, saya tidak mengerti mengapa mereka tidak menerimanya.

Masalah ini harus dibuka kembali karena diskusi tidak memiliki alasan yang baik untuk tidak melaksanakan permintaan ini. Orang-orang lebih cenderung mulai mengerjakan masalah _terbuka_ daripada yang tertutup.

Fakta bahwa masalah "tertutup" ini tetap begitu aktif menunjukkan bahwa itu belum ditangani dengan baik.

Sayangnya, saya menemukan bahwa tanggapan untuk menerbitkan posting di beberapa repo GitHub tidak terlalu membantu. Nadanya sering singkat, dan menunjukkan bahwa umpan balik kurang diterima.

Beberapa telah menunjukkan di sini bahwa ini adalah proyek sumber terbuka, dan (setidaknya sebagian besar dari kita) tidak membayar pelanggan. Namun, perlu diperhatikan juga bahwa mengirimkan laporan masalah merupakan investasi waktu yang signifikan, terlebih lagi jika Anda berpartisipasi dalam penyelesaian masalah.

Seorang pengguna atau pengembang, setelah menghabiskan waktu memecahkan masalah, dan menemukan solusi, kemudian akan memutuskan apakah mereka ingin menghabiskan waktu tambahan untuk melaporkannya. Respons yang tidak dapat diterima dari pengelola kemungkinan akan mengakibatkan mereka memilih untuk tidak mengganggu waktu berikutnya.

Perangkat lunak ini tidak benar-benar "GRATIS", dalam arti "bir gratis". karena kita semua mencoba untuk berpartisipasi dalam membuatnya lebih baik. Memiliki orang yang mau menguji perangkat lunak Anda dan memberikan umpan balik adalah sumber daya yang berharga. Mereka yang memiliki keterampilan pemrograman yang diperlukan bahkan bersedia menyumbangkan kode, tetapi mereka menginginkan semacam indikasi bahwa kontribusi mereka diterima sebelum menghabiskan waktu untuk itu.

Jelas, komentar yang hanya mengeluh tentang masalah dan menuntut agar diperbaiki tidak berguna, tetapi sebagian besar tidak melakukan itu, dan komentar seperti "ini open source, fork saja" sama-sama tidak berguna.

@shin- Mengapa "--build" diterapkan? Apakah ini berbeda dari build docker-compose && docker-compose up? Hanya mencoba memahami perbedaan filosofis antara --build (yang ditambahkan) dan --pull (yang dianggap berlebihan). Memahami proses berpikir mungkin membantu saya mengingat bagaimana segala sesuatunya bekerja. DAN jika masalah dibuka, saya dengan senang hati mengirimkan PR. @everybodyelse... apakah itu benar-benar "semangat opensource" yang jika Anda tidak menyukai sesuatu yang Anda garpu? Saya pikir semangat opensource adalah "jika Anda tidak menyukai sesuatu, Anda a) membantu berkontribusi pada persyaratan jika Anda berada di sana, b) membantu berkontribusi pada kode jika Anda bisa" dan Anda hanya bercabang jika persyaratan Anda sangat jelas sesuatu yang hanya Anda akan mendapatkan keuntungan dari. yaitu saya pikir kita paling diuntungkan ketika kita berbagi - tapi saya senang dididik di sini.

Setelah dua tahun bersikeras, memberikan alasan bagus yang diabaikan dan dukungan komunitas yang sangat besar agar ini benar-benar diterapkan, saya akan mengatakan bahwa fitur ini tidak akan berhasil hanya karena @shin- tidak mau. Tidak ada alasan untuk terus bersikeras.

Ada satu alasan: buruh pelabuhan tidak akan menyegarkan gambar jika satu tarikan gagal dan tidak ada alasan bagus untuk tidak melakukannya.

Saya mencari kebijakan tarik gambar kubernetes di docker compose, akan lebih bagus jika "tarik" dapat digunakan.

@shin- Berhenti bersikap kekanak-kanakan. Banyak alasan bagus untuk mengimplementasikan fitur ini telah disebutkan. Setidaknya terbuka untuk PR...

Anda boleh tidak setuju dengan saya, tetapi saya kecewa karena Anda menggunakan ad hominem, @Wenzil. Komunitas kami umumnya memiliki standar yang lebih tinggi.

@shin- Komunitas kami kebanyakan berpikiran sama untuk tidak mengatakannya karena alasan yang Anda sebutkan. @Wenzil hanya cukup jujur ​​untuk mengatakannya dengan lantang.
Banyak orang yang saya kenal memilih untuk tidak repot dan menyerah untuk mencoba meyakinkan docker-compose untuk beralih ke penggunanya.

Banyak orang tidak setuju @shin- untuk alasan yang sangat valid dijelaskan. Paling tidak, ini harus menjadi deklarasi layanan. Merangkai perintah bash bersama-sama bukanlah solusi yang sangat baik untuk penerapan terprogram.

Banyak orang yang saya kenal memilih untuk tidak repot dan menyerah untuk mencoba meyakinkan docker-compose untuk beralih ke penggunanya.

Ini. Dan itu bukan hanya docker-compose. Docker-stack, docker-machine, dan docker-cli semuanya serupa.

https://github.com/docker/compose/issues/6316#issuecomment -438564025

Mengunci karena ini terus tergelincir. Kami akan mengevaluasi kembali tergantung pada nasib https://github.com/docker/cli/pull/1498

Sebagai pembaruan, kami telah memutuskan secara internal untuk menambahkan parameter pull_policy ke definisi layanan. Kami masih harus mencari tahu apa opsi dan sintaks yang tepat, tetapi kami berharap itu akan memenuhi kebutuhan yang diungkapkan di utas ini.