Compose: Skema penamaan default untuk container yang dibuat oleh Compose

Sayangnya tidak, maaf.

Hal yang sama disini. Fitur siput ini harus opsional. Seberapa sulit untuk mengoper bendera di atas atau membangun perintah untuk mematikannya?

Saya setuju - ini harus opsional. Beberapa program yang menggunakan Docker Compose sekarang hanya berjalan jika Anda menurunkan versinya ke 1.22.

Saya setuju, ini harus opsional. Kami tidak memerlukan fitur slug ini sama sekali dan banyak skrip bash menggunakan format penamaan lama.

Sama untuk kami, kami harus tetap menggunakan 1.22 karena kami menggunakan fitur "volume dari" dan mengandalkan skema penamaan lama. Tolong, jadikan itu fitur opsional di 1.24.

Fitur ini menyulitkan untuk merujuk ke penampung setelah dinaikkan.

Saya tidak mengerti maksud dari perubahan ini. Saat ini baik buruh pelabuhan maupun menulis tidak menawarkan penemuan layanan apa pun. Jadi, jika saya ingin mendapatkan nama host dari dalam penampung, apa yang harus saya lakukan? Gulung penemuan layanan saya sendiri?

BTW, apa keuntungan dari perubahan ini? Apakah benar-benar layak melanggar kompatibilitas mundur?

Perubahan nama _slug default adalah pendekatan yang benar, tetapi tidak memiliki cara untuk menonaktifkannya melalui variabel lingkungan atau opsi baris perintah merusak banyak alur kerja yang ada. Harap pertimbangkan ini sebagai permintaan fitur untuk menambahkan semacam flag untuk mengembalikan perilaku penamaan <= 1.22.0 docker-compose.

Maaf, tapi "external_links" tidak dapat digunakan sekarang. Saya harus tahu nama wadah untuk menautkannya.
1 untuk menjadikannya opsional

@ shin- perilaku baru ini benar-benar menghancurkan banyak hal. Sebelum slug acak itu, adalah mungkin untuk menangani wadah yang diluncurkan dari satu file pembuat galangan di dalam file lain seperti

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

Dan itu dia. Sekarang, ini tidak akan berhasil sama sekali.

Bagaimana hal ini setidaknya bukan opsional?

Saya yakin, satu langkah lagi menuju kematian buruh pelabuhan.

Jadi, ada solusinya. container_name parameter digunakan sebagaimana adanya dan slug tidak digunakan di atasnya. Setidaknya, itu membantu.

@ shin- tolong, jangan anggap ini sebagai laporan bug tentang slug tidak digunakan dengan container_name . Biarkan apa adanya. Saya benar-benar mengantongi di sini.

Oh Boy! https://github.com/ansible/ansible/issues/47978

Meskipun saya memahami insentif di balik perubahan tersebut, hal ini sangat mengganggu, terutama karena tidak ada masa tenggang untuk setidaknya memberi waktu kepada pengembang untuk menyesuaikan skrip mereka. Banyak skrip ditulis dengan mempertimbangkan konvensi penamaan yang ada secara harfiah selamanya. Pada dasarnya, perubahan ini membuat docker-compose 1,23 kompatibel dengan docker-compose lainnya.

@ shin- Anda secara pribadi dan semua tim docker-compose dan docker harus sudah mempelajari apa itu perubahan yang tidak kompatibel dengan versi sebelumnya dan bagaimana membawanya ke proyek yang diadopsi secara luas yang diandalkan oleh seluruh industri.

Pertama, perubahan yang tidak kompatibel ke belakang bukanlah tentang Anda melanggar apa yang telah Anda jamin sebelumnya untuk tidak melakukannya. Tidak ada yang peduli jika benda ini digunakan oleh siapa pun.

Perubahan yang tidak kompatibel ke belakang adalah saat Anda merusak sesuatu yang sebenarnya diandalkan oleh basis pengguna Anda. Dan tidak peduli apa jaminannya karena itu Apache 2.0 dan keseluruhan proyek provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND . Pengguna Anda memutuskan apa yang mereka andalkan. Dan Anda (seluruh tim) harus mulai belajar bagaimana menyadari siapa yang menggunakan proyek Anda, mengapa, dan bagaimana.

Kedua, Anda harus belajar bagaimana memperkenalkan perubahan seperti itu ke basis pengguna Anda. "Hal sufiks acak" ini jelas merusak cara pengguna Anda menggunakan external_links dan volumes_from . Jadi, peringatan penghentian jika tidak ada set container_name eksplisit atau jika terlihat seperti itu akan sangat dihargai. Harap pertimbangkan dokumen-dokumen berikut untuk memahami "apa yang dilakukan orang lain":

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation -policy

Ketiga, @ shin-, Anda secara pribadi harus belajar bagaimana berbicara dengan orang-orang yang bukan kontributor langsung untuk proyek Anda dan yang hanya pengguna Anda tetapi pada saat yang sama mereka adalah orang-orang yang sangat sibuk yang setia pada proyek Anda cukup untuk menginvestasikan mereka yang berharga waktu mengajukan permintaan dan berpartisipasi dalam diskusi di sini dengan satu-satunya harapan untuk memberikan pengertian pada pengembangan proyek di masa depan dan untuk mencoba menghindari investasi lebih banyak sumber daya dalam migrasi ke solusi lain.

Keempat, tim Docker mencoba menghasilkan uang dari Docker tetapi ini bukan tentang Docker itu sendiri. Satu-satunya cara Docker bisa menjadi hal yang baik untuk dibayar adalah jika seluruh infrastruktur Docker membuktikan bahwa itu layak untuk dibayar. Saya tidak melihat bagaimana ini adalah produk yang berorientasi pada kesuksesan pengguna jika tim pengembangan sebagian besar waktu membelakangi komunitas.

Kelima, sekali lagi, kami semua di sini adalah perguruan tinggi dan teman Anda, bukan musuh, dan kami benar-benar berusaha membantu Anda dengan semua ini. Dan karena kami adalah teman-temanmu, eksodus dari tumpukan buruh pelabuhan akan menyakitkan tetapi dalam perjalanannya, perpisahan itu tidak terlihat tidak realistis sama sekali.

Ini adalah implementasi yang buruk dari perubahan besar yang merusak versi, ini benar-benar merusak kemampuan untuk menerapkan kerangka kerja kami dan saya bahkan tidak dapat membayangkan berapa banyak orang lain yang akan mengalami masalah yang persis sama, dengan peringatan awal yang sama sekali nol; kecuali seseorang secara manual mencari changelogs terbaru untuk buruh pelabuhan, mereka tidak tahu tentang ini, dan saya membayangkan kebanyakan orang tidak akan melakukannya

@ shin- Perubahan ini sangat mengganggu alur kerja yang ada dan harus ada bendera yang disediakan untuk tidak menghasilkan siput. Ribuan jam waktu pengembangan telah digunakan untuk menulis skrip dan mengotomatiskan layanan yang mengandalkan prediktabilitas docker-compose. Tanpa penemuan layanan yang tepat, apa rencana tim untuk mengizinkan penargetan otomatis setiap penampung?

Saya mencoba menggunakan perintah docker-compose container_name tetapi tidak berpengaruh pada GitLab.
Tetapi tampaknya pada versi terbaru saya docker-compose pada Mac Os Mojave ini berfungsi. Tidak yakin apa yang terjadi :)

File .gitlabci.yml sedang mengunduh gambar terakhir dari tmaier (seharusnya 1.23.1).

Halo semuanya, beberapa komentar umum yang saya harap dapat menjawab beberapa kekhawatiran yang diungkapkan di sini:

• Saya sangat mengerti bahwa ini merusak beberapa skrip. Catatan rilis kami sejak 1.23.0-rc1 mengatakannya di bagian paling atas. Ini adalah jenis situasi "merobek bandaid" di mana rasa sakit sesaat membantu kita bergerak maju dengan dasar yang lebih sehat.
• Manfaat dari solusi saat ini sangat banyak dan sebagian dinyatakan dalam masalah yang telah berlangsung lama ini: # 1516 - dan masalah dengan docker-compose run khususnya telah dilaporkan beberapa kali di sini: # 4688 # 4549 # 5240
• Penemuan layanan seharusnya tidak menjadi masalah karena harus ditangani menggunakan nama layanan (bukan nama kontainer) dan alias jaringan, yang statis di jaringan terkait. Anda dapat membaca dokumen jaringan untuk lebih jelasnya secara spesifik
• Menurut saya ini membuat volumes_from dan external_links di seluruh proyek Compose lebih sulit digunakan. Harap pertimbangkan bahwa bahkan sebelum perubahan ini, tidak ada jaminan bahwa Compose akan mengikuti format "yang diharapkan" untuk nama penampung tertentu (lihat misalnya # 6155 atau awalan yang disebutkan di # 3415), menjadikannya solusi cacat yang cenderung berjalan menjadi masalah yang tidak jelas dalam jangka panjang.
  
  
  
  • Cara yang disarankan untuk mengizinkan kontainer dari proyek berbeda untuk berkomunikasi adalah dengan berbagi jaringan external dan menggunakan alias layanan lain. Demikian pula, volumes_from di seluruh proyek seharusnya memanfaatkan external volume bernama.
  
  
• Saya tertarik dengan saran tentang bagaimana perubahan ini dapat dikomunikasikan dengan lebih baik. Sebagai referensi, perubahan tersebut telah disebutkan dalam catatan rilis kami dan tersedia untuk pengujian sejak 1.23.0-rc1, yang dirilis 26 September. 1.23.0 GA dirilis lebih dari sebulan kemudian, dan mengetahui perubahan tersebut akan menjadi kontroversial, kami menempatkannya sebagai peringatan besar di bagian atas log perubahan. Jika ada hal lain yang bisa saya lakukan untuk membuat perubahan ini terlihat, saya senang mendengarkan dan melakukan hal-hal ini saat kita mempertimbangkan perubahan berisiko seperti ini.
  
  
  
  • Di sisi lain, jika kesimpulan umum di sini adalah "jangan pernah membuat perubahan yang merusak, atau biarkan saya memilih keluar dari semuanya tanpa batas", saya yakin sebagian besar dari Anda menyadari bahwa ini bukan cara yang sehat dan masuk akal untuk melakukannya tentang memelihara proyek perangkat lunak seukuran Compose, yang sudah melewati banyak rintangan untuk mempertahankan kompatibilitas ke belakang dengan beragam versi Docker Engine, format file Compose, dan idiom yang tidak digunakan lagi.
  
  

Beri tahu saya jika ada sesuatu yang tidak dibahas di sini. Saya mengerti bahwa ini adalah rintangan utama bagi banyak dari Anda dan emosi mungkin berkobar ketika kita menghadapi keadaan yang tidak terduga. Luangkan waktu yang Anda perlukan untuk melakukan peningkatan dan pasang pin versi Tulis Anda untuk saat ini. Senang membantu dengan pertanyaan seperti "Bagaimana cara melakukan XYZ tanpa nama yang dapat diprediksi?" sampai saat itu, di utas ini atau di Slack. Dan harap perhatikan cara Anda berinteraksi dengan orang lain di forum ini, periksa kembali apakah informasi yang Anda bagikan benar (saya telah melihat beberapa utas disebutkan atau dialihkan ke sana yang tidak ada hubungannya dengan perubahan ini , yang menciptakan rasa khawatir yang tidak perlu dan tidak membantu orang-orang dengan masalah yang salah arah di sini), dan tidak menggagalkan percakapan. Terima kasih atas waktu dan kesabaran Anda.

Pada bagian komunikasi, saya mengharapkan perubahan seperti ini dikomunikasikan dan dijelaskan melalui beberapa saluran komunikasi sebelumnya, pada dasarnya seperti yang Anda lakukan di sini di utas ini, menjelaskan mengapa, dan apa yang harus dilakukan untuk saat ini, tetapi melakukannya sebelumnya semua akibatnya.

@ shin- Anda belum membaca komentar dan tautan terakhir saya yang saya berikan, bukan?

Yang terakhir dari Anda terlihat baik tetapi terasa sama.

Saya tertarik dengan saran tentang bagaimana perubahan ini dapat dikomunikasikan dengan lebih baik.

TL; DR

• Perkenalkan version dari docker-compose.yml
• Tambahkan DeprecationWarning untuk external_links dengan tautan ke dokumen yang menjelaskan pembaruan dan memberikan contoh solusi bagi mereka yang ingin bermigrasi.
• Mendukung perilaku lama untuk semua versi format file tulis sebelum yang baru.

Sebagai referensi, perubahan tersebut telah disebutkan dalam catatan rilis kami

Changelog adalah hal bagi kontributor. Pengguna tidak membacanya. Seorang pengguna menginstal docker-compose dan berharap itu masih berfungsi setelah kemarin.

Di sisi lain, jika kesimpulan umum di sini adalah "jangan pernah membuat perubahan yang merusak, atau biarkan saya memilih keluar dari semuanya tanpa batas", saya yakin sebagian besar dari Anda menyadari bahwa ini bukan cara yang sehat dan masuk akal untuk melakukannya tentang memelihara proyek perangkat lunak seukuran Compose, yang sudah melewati banyak rintangan untuk mempertahankan kompatibilitas ke belakang dengan beragam versi Docker Engine, format file Compose, dan idiom yang tidak digunakan lagi.

Saya punya kabar baik untuk Anda. Anda sudah menjamin "jangan pernah membuat perubahan yang merusak, atau biarkan saya menyisih dari semuanya tanpa batas". Dan lebih banyak lagi, Anda memiliki fitur untuk ini. Ini adalah file version dalam docker-compose.yml . Jadi, pertimbangkan untuk mengembalikan perubahan ini secepatnya dan memperkenalkannya untuk angka version .

Senang membantu dengan pertanyaan seperti "Bagaimana cara melakukan XYZ tanpa nama yang dapat diprediksi?" sampai saat itu, di utas ini atau di Slack.

Tolong, berikan solusi untuk external_links dan volume eksternal tanpa container_name ditentukan (seperti yang kita lihat tidak selalu berhasil) di docker-compose.yml di utas ini.

Ini adalah cara populer pengguna Anda menggunakan proyek Anda. Sebagian besar pengguna Anda menggunakan docker-compose untuk pengembangan lokal. Seringkali seseorang memiliki beberapa proyek yang saling berhubungan dalam pengembangan. Dalam kasus seperti itu, merupakan praktik umum untuk mengarahkan beberapa file docker-compose ke jaringan yang sama dan menentukan external_links untuk layanan dari proyek yang berbeda agar dapat saling menjangkau di mesin pengembang.

jangan menggagalkan percakapan

@ shin- Semua percakapan yang telah saya baca sejauh ini yang melibatkan Anda menjadi tergelincir karena Anda tidak melakukan apa pun untuk menyelesaikan masalah yang dimiliki orang.

Serius, dengan sikap seperti itu terus-menerus menolak permintaan pengguna dan memaksa komunitas Anda berjuang ketika Anda dapat menghindari bahwa Anda lebih baik meneruskan proyek ini kepada orang lain.

PS: Maaf untuk komentar "offtopic" lainnya. Jangan ragu untuk mengunci masalah ini karena Anda juga sudah terbiasa.

Harap berikan solusi untuk external_links dan volume eksternal tanpa container_name yang ditentukan (seperti yang kita lihat tidak selalu berfungsi) di docker-compose.yml lain di utas ini.

Sudah melakukannya, silakan lihat komentar saya sebelumnya:

Cara yang disarankan untuk mengizinkan kontainer dari proyek yang berbeda untuk berkomunikasi adalah dengan membagi jaringan external dan menggunakan alias layanan lain. Demikian pula, volumes_from di seluruh proyek seharusnya memanfaatkan external volume bernama.

Sisa dari posting Anda tidak perlu bermusuhan dan saya tidak akan menanggapinya. Saya di sini dan ingin berdiskusi, tetapi saya tidak perlu menerima perundungan Anda.

Jujur, @ shin-

Saya tertarik dengan saran tentang bagaimana perubahan ini dapat dikomunikasikan dengan lebih baik

Saya tidak melihat Anda "tertarik". Menutup tiket tentang menarik gambar sebelum membuat file tulis dan menandainya sebagai "spam" (lol) memberi tahu saya bahwa Anda pasti tidak tertarik dengan saran komunitas. Saya benar-benar tidak tahu apa yang ingin Anda capai tetapi saya merasa bahwa menjaga hubungan dengan komunitas harus dipegang oleh orang lain.

Saya di sini dan ingin berdiskusi

Meskipun kami memberikan argumen meritoris murni, Anda mengabaikannya. Jadi kenapa repot-repot?

PS. Tandai ini sebagai offtopic, silakan, tunjukkan kepada kami bagaimana Anda menghargai pendapat kami. Sakit?

Sudah melakukannya, silakan lihat komentar saya sebelumnya:

Saya tidak melihat solusi sampel yang berfungsi di sana, maaf.

Sisa dari posting Anda tidak perlu bermusuhan dan saya tidak akan menanggapinya. Saya di sini dan ingin berdiskusi, tetapi saya tidak perlu menerima perundungan Anda.

Maaf, jika Anda merasa seperti itu. Harap pertimbangkan untuk mendukung perilaku lama untuk versi file tulis buruh pelabuhan saat ini dan perkenalkan versi format baru yang akan berperilaku dengan cara baru. Ini adalah satu-satunya pilihan yang Anda miliki untuk memberikan solusi yang baik untuk basis pengguna Anda.

Silahkan. pertimbangkan untuk membaca dua komentar saya ini lagi dengan gagasan bahwa saya bersedia membantu proyek dalam pikiran Anda:

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

Re komunikasi: Kami mendapat pembaruan melalui Docker untuk Mac, dan tampaknya tidak menunjukkan log perubahan apa pun yang menunjukkan perubahan ini, jadi butuh sedikit waktu untuk mencari tahu mengapa variabel lingkungan kami berubah.

Setelah saya menyadarinya, saya menganggapnya sebagai kesempatan untuk meningkatkan konfigurasi kami dari v1 ke v3 dan menautkan menggunakan nama layanan alih-alih variabel lingkungan, dan itu sebenarnya membuat semuanya jauh lebih bersih 👍

FWIW, peretasan yang kompatibel ke belakang untuk dieksekusi dalam wadah yang dibuat dengan menulis:

docker container exec -it $(docker container ls -f name=expected -q) cmd

Setelah saya menyadari hal ini, saya menganggapnya sebagai kesempatan untuk meningkatkan konfigurasi kami dari v1 ke v3 dan menautkan menggunakan nama layanan alih-alih variabel lingkungan, dan itu sebenarnya membuat segalanya jauh lebih bersih

Bisakah Anda memberikan contoh singkat di sini untuk nama layanan yang menautkan di berbagai pendekatan file tulis-buruh pelabuhan?

docker container exec -it $(docker container ls -f name=expected -q) cmd

Ini tidak ada hubungannya dengan penulisan buruh pelabuhan.

@lig Ini bekerja untuk mengubah nama expected dibuat oleh docker-compose. Solusi ini tidak akan ada jika bukan karena perubahan dalam skema penamaan.

@joebowbeer masalah utama setelah perubahan ini adalah tentang menghubungkan antar file docker-compose. Begitu, ada cara untuk menemukan container yang diluncurkan oleh docker-compose melalui docker cmd. Tapi ini sedikit membantu tentang masalah ini :(

@ shin- Saya rasa kita semua masih menunggu penjelasan mengapa kita membutuhkan komposer buruh pelabuhan untuk menghasilkan nama kontainer garis gerombolan.

Bagi saya, cukup jelas tidak ada orang dalam keadaan waras yang perlu menggunakan komposer untuk tujuan produksi. Tulis adalah cara yang ampuh untuk meningkatkan proyek untuk diuji secara lokal. Saya tidak melihat daya tarik untuk mendapatkan fitur / fungsi kawanan buruh pelabuhan ke alat yang banyak digunakan untuk pengujian khusus lokal. Jika kami membutuhkan nama seperti swarm untuk kontainer, kami akan menggunakan swarm. Baik?

Pertanyaan besar kedua di sini adalah: Mengapa ini tidak dimasukkan sebagai fitur opsi melalui argumen? Saya tidak melihat di forum dan komunitas saya orang-orang yang mengajukan banding untuk memiliki perilaku ini sebagai perilaku default. Jadi kita mungkin harus memperkenalkannya sebagai argumen baru: docker-compose up --slug . Sederhana, elegan, dan tidak akan merusak skrip siapa pun.

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

Bekerja di perusahaan, di masa lalu, kami cenderung memiliki aturan "dua versi utama" tentang melanggar perubahan - tidak berlaku lagi di satu versi, hapus di versi berikutnya. Saya tidak begitu yakin bagaimana hal ini bisa dijadikan keikutsertaan, tetapi penyisihan _ sementara_ akan sangat dihargai.

Docker-compose tampaknya tidak memiliki konsep versi mayor, tetapi saya tidak melihat bagaimana opsi "nonaktifkan ini" sementara (baik dari baris perintah atau di file penulisan) terbatas pada satu atau dua rilis (1,23 dan mungkin 1,24) akan merupakan "tanpa batas."

Mengingat bahwa ini tampaknya terkait dengan pembaruan otomatis untuk pengguna non-Linux, banyak orang terkejut, dan alih-alih memiliki sisa kuartal untuk "dijalankan dengan bendera baris perintah ini sementara kami memperbarui skrip kami" kami memiliki sejumlah besar pengembang yang harus menurunkan versi secara manual dan / atau menghentikan apa yang mereka lakukan untuk memperbarui skrip.

Perubahan yang menghancurkan ini adalah bencana. Mendadak banyak penyebaran otomatis. Tolong jangan lakukan itu lagi.

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

Masuk akal ... tidak tahu mengapa tidak dilakukan seperti ini.

Saya di sini dan ingin berdiskusi, tetapi saya tidak perlu menerima perundungan Anda.

@ shin- cukup jelas tidak ada diskusi di sini karena Anda tidak mempertimbangkan saran rasional yang disajikan. Selain itu, jika ada yang menjadi penindas - Anda - dengan perubahan besar ini, Anda secara efektif menindas banyak pengembang di seluruh dunia.

Banyak orang (saya dan beberapa orang lain mungkin) tidak menggunakan compose untuk mode swarm. Saya menentukan versi yang lebih rendah untuk file tulis saya karena masalah yang pernah saya alami di masa lalu di mana asumsinya adalah file tulis digunakan untuk menentukan layanan untuk swarm. Saya membayangkan bahwa versi yang saya tentukan terkait dengan hasil yang dihasilkan pada node buruh pelabuhan saya dan dengan mengunci versi ke sesuatu yang rendah, saya bisa mendapatkan hasil yang konsisten dan masih melakukan pembaruan untuk menulis agar tetap kompatibel dengan versi buruh pelabuhan Saya sedang berlari. Rupanya saya tidak bisa mengharapkan versi yang tepat di sini.

Bisakah kita melakukan dockerize pada docker-compose, untuk memastikan mereka tidak tiba-tiba merusak barang kita?

Saya pikir solusi terbaik adalah memperkenalkan opsi konfigurasi baru di file docker-compose.yml di mana menambahkan bagian siput ke nama wadah dapat dinonaktifkan.

s / dinonaktifkan / diaktifkan /. Setidaknya pada versi file tulis yang sudah ada.

Perilaku ini perlu dikaitkan dengan nomor versi file penulisan. Terlepas dari apakah perilaku ini "ditentukan", ini cukup banyak digunakan, dan karena itu merupakan perubahan yang tidak kompatibel dengan versi sebelumnya. Mengapa versi spesifikasi pada saat itu juga jika apa yang tidak dijamin oleh file tulis tidak dijamin akan berfungsi dengan cara yang sama ketika saya meningkatkan biner saya? Menghentikan spesifikasi file penulisan (dengan banyak peringatan ketika docker-compose dijalankan tentunya) dan kemudian menghapusnya, itu pasti salah saya semua barang saya tidak lagi berfungsi, tetapi mengharapkan saya membaca rilis Anda catatan untuk program yang memiliki hak istimewa untuk mencetak pesan peringatan di wajah saya?

Membuat perubahan seperti ini tampaknya merupakan motivasi yang cukup baik untuk membuat versi perilaku spesifikasi selain formatnya: Anda dapat menghentikan asumsi kode orang lain dengan peringatan. Saya pikir jumlah masalah eksternal yang mengesampingkan masalah ini menunjukkan betapa mengejutkannya hal ini bagi banyak orang. Sangat menyenangkan melihat perilaku lama dihancurkan sehingga kode tidak menjadi rumit, tetapi perubahan seperti itu tidak dapat diterapkan sekaligus. Dapatkah saya mengharapkan asumsi lain tentang penulisan nama penampung rusak? Akankah nama layanan selalu dalam nama penampung atau dapatkah itu dihapus seperti nama yang dapat diprediksi?

Ini benar-benar mengingatkan saya ketika Konsisten Penamaan Perangkat Jaringan menerima adopsi luas di Linux (tetapi ini adalah hal yang berlawanan dengan penamaan ... idk). Banyak kode yang di-hardcode untuk ethN (dan masih di beberapa tempat yang mengejutkan) dan itu tidak benar-benar berubah. Namun ada cara untuk mendapatkan kembali perilaku lama pada sistem systemd (dan sistem lain, tetapi dapat bervariasi) dengan menambahkan net.ifnames=0 ke args kernel.

(Maaf untuk kata-kata kasar kedua, tapi menurut saya yang pertama tidak terlalu membangun.)

Tampaknya perubahan ini membuat opsi --scale tidak berguna. karena postfix acak harus diketahui untuk menjangkau contoh skala layanan.

Misalnya, beberapa instance layanan sebagai server upstream untuk Nginx.

Edit: lihat # 6365 untuk informasi lebih lanjut

Wow, perubahan yang luar biasa. 👎

Bagaimana kita bisa mendapatkan string yang dibuat secara acak untuk digunakan dalam skrip?

Saya mengalami masalah ini juga dan ingin mengungkapkan rekomendasi saya untuk perubahan yang tidak kompatibel dengan versi sebelumnya. Kami juga memiliki skrip yang mengandalkan format project_service_index, dengan banyak orang menggunakan skrip tersebut di Mac. Di dunia yang ideal, kami akan dapat mengontrol versi Docker untuk Mac yang digunakan orang-orang, tetapi untuk saat ini orang meningkatkan saat dialog peningkatan otomatis muncul.

Masalah dan rekomendasi saya adalah:

1) Dialog peningkatan tidak memiliki indikasi perubahan signifikan ini, jadi kami tidak memiliki pemberitahuan yang jelas tentang perubahan ini. Idealnya, kami akan memeriksa semua catatan rilis untuk setiap peningkatan, tetapi saat ini kami tidak melakukannya. Jadi, akan sangat dihargai jika sesuatu yang signifikan seperti ini dipanggil dalam dialog pembaruan secara eksplisit.

2) Karena 1), tidak ada peringatan yang jelas. Akan lebih bagus jika perubahan seperti ini dipanggil di peningkatan sebelumnya. Misalnya, peningkatan sebelum versi terbaru akan mengatakan sesuatu seperti "skema penamaan penampung berubah di versi berikutnya, harap tingkatkan skrip Anda"

3) Saya memahami bahwa, setelah membaca utas ini, skema penamaan yang kami gunakan tidak dijamin, dan saya menyadari ada cara yang lebih baik untuk merujuk ke container. Namun, kita semua memiliki kehidupan kerja yang sibuk dan perlu merencanakan tugas kita, jadi sebagai pengelola skrip kita, saya tidak dapat mengubah penggunaan nama wadah kita menjadi sesuatu yang lebih baik dengan segera. Saya senang menggunakan praktik terbaik yang disarankan, tetapi perlu waktu untuk memindahkan kode kami. Oleh karena itu, akan sangat bagus untuk memiliki strategi penghentian untuk perubahan seperti ini.

Kuncinya di sini adalah sebagian besar dunia mengasumsikan skema penamaan container yang fundamental untuk penggunaan docker compose mereka, dan mengubah perilaku default tanpa strategi penghentian yang jelas dapat merusak alur kerja ini.

Orang-orang tidak selalu menggunakan perangkat lunak persis seperti yang dimaksudkan, dan kepemilikan ada pada orang-orang itu untuk memperbaiki keadaan ketika asumsi mereka gagal. Namun, beberapa komunikasi sederhana dapat membantu kami mempersiapkan diri untuk perubahan di masa mendatang dan akan membantu memotivasi kami untuk beralih ke praktik terbaik terbaru.

Jika sebelumnya Anda bergantung pada docker container exec -it project_php_1 bash , Anda tidak dapat lagi menggunakan ini.

Anda harus menggunakan docker ps untuk menemukan ID layanan.

Namun, Anda tidak dapat menggunakan docker ps -q --filter=name=project_php karena itu akan cocok dengan layanan bernama project_php dan project_php_xdebug atau apa pun yang menyisakan project_php .

docker container exec -it project_php_1 bash sebelumnya dapat dibaca sekarang harus menjadi ini:

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

Ini adalah perubahan yang dipikirkan dengan buruk.

@jtreminio FWIW, dari proyek ini Anda masih dapat melakukan docker-compose exec php

Terima kasih kepada semua orang yang meluangkan waktu untuk membagikan pemikiran mereka tentang perubahan ini. Kami setuju ini ditangani dengan buruk dan agak terlalu bersemangat di pihak kami, dan sebagian telah dikembalikan di Compose 1.23.2 (kami menyimpan sufiks acak untuk container yang dibuat oleh docker-compose run , yang memungkinkan kami menangani ini dengan lebih anggun : # 4688 # 4549 # 5240, seperti yang awalnya dimaksudkan).

Beri tahu saya jika ada masalah luar biasa yang perlu ditangani.

Apakah ada rencana untuk menambahkan opsi baris perintah untuk mematikan ini --no-slug atau lebih disukai --slug sehingga defaultnya berfungsi seperti dulu.

1.23.2 kembali ke keadaan sebelumnya.

Itu hanya dikembalikan sebesar docker-compose up tetapi tidak untuk docker-compose run

Terima kasih atas penyelesaian cepat ini !!

Pada 28 Nov 2018, pukul 20:09, Joffrey F [email protected] menulis:

Terima kasih kepada semua orang yang meluangkan waktu untuk membagikan pemikiran mereka tentang perubahan ini. Kami setuju ini ditangani dengan buruk dan agak terlalu bersemangat di pihak kami, dan sebagian telah dikembalikan di Compose 1.23.2 (kami menyimpan sufiks acak untuk container yang dibuat oleh proses penulisan docker, yang memungkinkan kami menangani ini dengan lebih anggun: # 4688 # 4549 # 5240, seperti yang awalnya dimaksudkan).

Beri tahu saya jika ada masalah luar biasa yang perlu ditangani.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

@ shin- Saya berasumsi bahwa ini akan dikembalikan di beberapa titik - mungkin di 1,24 (karena ini adalah perubahan yang sangat penting?). Jika demikian, dapatkah Anda bekerja dengan komunitas untuk memahami dan merekomendasikan mekanisme ringan alternatif untuk orang yang menggunakan ini tanpa siput? Tidak yakin tentang tempat terbaik untuk melakukan percakapan itu.

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

diubah dari <project>_<service>_<index> menjadi <project>_<service>_<index>_<slug>

Ini adalah bug, bukan fitur.
Terima kasih!
Pikirkan tentang kemungkinan pedoman yang berjalan dengan ansible_connection=docker ... 😔 !!
haruskah kita memberikan container_name secara eksplisit? atau akankah kami terus memperbarui inventaris kami dengan acak <slug> !!.
Benar-benar sangat buruk!