Compose: Depends_on di versi3

depends_on masih ada di v3, tetapi dependensi healthcheck (dan akibatnya, sintaks yang diperpanjang) tidak akan dipindahkan.

HTH

Tetapi saya telah menulis sebuah docker-compose v3 dan saya mencoba untuk menyebarkan pada swarm tetapi depend_on tidak berfungsi karena penampung tidak dimulai dengan cara di mana mereka harus dimulai.

Apakah Anda menggunakan docker-compose atau docker stack deploy ?

Saya menggunakan penerapan tumpukan buruh pelabuhan
dan saya mencoba untuk menyebarkannya pada segerombolan 7 mesin

Apa yang setara pada docker-compose v3 untuk mencapai sesuatu seperti dependensi healthcheck? Jika Anda akan menghentikan fungsionalitas itu di v3, pada dasarnya seseorang tidak boleh menggunakannya, atau setidaknya harus ada jalur migrasi untuk ini.

Apa niat untuk memperkenalkannya di docker-compose v2.1 baru dan kemudian menghapusnya untuk v3? Saat ini saya sedang menyiapkan file penulisan yang berbeda untuk aplikasi kita, tetapi saya tidak ingin menggunakan fitur yang dijatuhkan di versi berikutnya dan oleh karena itu mencegah penggunaan untuk memperbarui ke versi file docker-compose yang lebih baru.

Saat ini, Anda harus berasumsi bahwa sintaks depends_on baru tidak akan di-porting ke v3, karena saat ini kami tidak memiliki rencana untuk melakukannya.

Saya tahu itu bukan jawaban yang diinginkan banyak orang, tapi saya harap itu bisa membantu memberikan kejelasan.

Bolehkah saya bertanya mengapa tidak ada dalam rencana? Saya berasumsi akan sangat berguna untuk melakukannya.

Ini memberi kejelasan, tetapi tidak menjelaskan. Bisakah Anda menjelaskan alasannya? Dan tentang alternatifnya (jika ada)?
Depend_on memberi kita cara yang sangat mudah untuk bergantung pada layanan, dibandingkan dengan menanganinya di dalam penampung (yang mungkin berarti membungkus gambar pihak ketiga dengan beberapa skrip tunggu dan harus menjaganya).

@ shin- mengapa Anda menerapkannya di 2.1, lalu? Jika orang menggunakannya dan bergantung padanya, mereka tidak akan pernah bisa mengupgrade. Dengan segala hormat, sepertinya itu perencanaan yang sangat buruk di pihak kalian.

Jadi apa sintaks depends_on yang didukung untuk v3? https://docs.docker.com/compose/compose-file/#version -3 tidak menyebutkan depend_on, dan ketika saya menggunakan docker-compose v1.10 untuk menerapkan aplikasi, baik v2 atau v2.1 depend_on flavours tidak berfungsi untuk saya di file tulis v3 ...

@sukabumi_sukabumi

Bolehkah saya bertanya mengapa tidak ada dalam rencana? Saya berasumsi akan sangat berguna untuk melakukannya.

@buat

Bisakah Anda menjelaskan alasannya? Dan tentang alternatifnya (jika ada)?

Dari https://github.com/docker/docker/issues/30404#issuecomment -274825244

depends_on adalah no-op bila digunakan dengan docker stack deploy . Layanan mode swarm dimulai ulang ketika gagal, jadi tidak ada alasan untuk menunda startup mereka. Bahkan jika gagal beberapa kali, pada akhirnya akan pulih.

@tokopedia

Jadi, apa sintaks depend_on yang didukung untuk v3?

Saat menggunakan docker-compose , sintaks yang didukung untuk v3 adalah sintaks daftar (mirip dengan yang digunakan untuk 2.0). Jika Anda menggunakan docker stack deploy , ketergantungan tidak akan diberlakukan (lihat di atas untuk pembenaran)

Format versi 3 adalah langkah pertama untuk menjauh dari alat eksternal docker-compose menuju solusi docker stack terintegrasi. Implementasi saat ini memiliki kebiasaan yang sedang dikerjakan. Dukungan untuk format versi 3 di docker-compose dimaksudkan untuk membantu transisi itu. Banyak hal telah berubah dan ditingkatkan di Docker sejak fig / Compose pertama kali diperkenalkan, dan itu berarti banyak hal yang dulunya masuk akal sekarang telah menjadi usang. docker stack adalah permulaan baru menggunakan konsep baru dan membuang beberapa sintaks dan konsep yang lebih sulit, dari volumes_from hingga depends_on .
Jika Anda memiliki kekhawatiran khusus tentang beberapa perubahan tersebut, laporkan ke repo buruh pelabuhan / buruh pelabuhan tempat perulangan aktif.
Jika Anda belum siap untuk beralih ke layanan Docker dan docker stack , jangan ragu untuk tetap menggunakan format v2. Meskipun masuk akal untuk mengasumsikan proyek akan berakhir di beberapa titik di masa depan, itu akan diumumkan jauh sebelumnya. Dan setelah itu kode akan tetap tersedia dan open source.

Terima kasih. Sekarang masuk akal.

Layanan mode swarm dimulai ulang ketika gagal, jadi tidak ada alasan untuk menunda startup mereka. Bahkan jika gagal beberapa kali, pada akhirnya akan pulih.

IMHO ini bukan pendekatan yang baik. Tidak semua layanan dapat dengan benar mendeteksi layanan lain yang mereka andalkan belum siap, mereka mencoba berkali-kali kemudian gagal, sehingga kontainer mungkin mati nanti. Kami masih perlu memperkenalkan skrip pembungkus entrypoint, yang tidak terlalu bagus. Ketergantungan cek kesehatan sangat bagus, tetapi hanya tidak mendukung mode swarm.

Layanan mode swarm dimulai ulang ketika gagal, jadi tidak ada alasan untuk menunda startup mereka. Bahkan jika gagal beberapa kali, pada akhirnya akan pulih.

Hai semuanya!
Apakah ini berarti bahwa jika misalnya saya memiliki layanan yang menjalankan dan menyelesaikan pekerjaannya dengan sangat cepat (dan seharusnya hanya dijalankan satu kali sesuai desain), layanan akan dimulai lagi dan lagi dan lagi ... berulang kali?

@ Marvel77 Secara default, ya, tetapi Anda dapat menimpa perilaku itu menggunakan bagian deploy.restart_policy : https://docs.docker.com/compose/compose-file/#restartpolicy

@ shin- Terima kasih banyak!

@mustafaakin Sebenarnya, praktik terbaiknya adalah (IMHO) memiliki koneksi toleransi kesalahan ke layanan yang Anda andalkan. Misalnya, jika Anda menggunakan database, Anda mungkin menunda startup hingga itu merespons. Tetapi bagaimana Anda menangani restart database? Aplikasi Anda seharusnya dapat pulih dari ini, dan Anda juga tidak perlu bergantung pada 'depend_on'.
Dalam arti tertentu, penghentian adalah hal yang baik. Kemudahan ini membuat kita malas.

@hsmade Tetapi hampir semua init (pemula, systemd) bergantung pada hubungan. Jadi bukan karena malas, itu yang masuk akal. Daemon SSHD tidak dimulai sampai Anda menyiapkan perangkat jaringan Anda. Saya tidak memiliki kendali atas semua sistem yang saya miliki, ya, saya dapat membuat sistem saya toleran terhadap kesalahan. Tetapi asumsikan A bergantung pada B. A membutuhkan waktu beberapa saat untuk menginisialisasi, itu tidak terlalu deterministik. Jadi, bagaimana Anda bisa menulis kebijakan restart di B? restart selamanya? Bagaimana jika Anda tidak menginginkannya?

Ini adalah masalah yang lebih besar daripada Tulis, Tulis baru saja memulainya. Swarm yang membuat mereka lari, jadi menurut saya Swarm harus menangani ketergantungan pada hubungan kesehatan ini.

@mustafaakin Saya rasa Anda tidak dapat membandingkan layanan mikro yang berjalan di lingkungan dalam container dengan sistem init klasik. Itu tidak masuk akal. Menurut saya, gagasan layanan mikro adalah bahwa mereka berdiri sendiri, entitas minimal. Mereka memiliki definisi yang sangat jelas tentang API mereka, dll. Mereka tidak boleh mengambil status apa pun dari dunia luar mereka. Ya, itu akan membutuhkan database, tetapi tidak, Anda tidak dapat berasumsi bahwa itu ada di sana. Seperti yang saya coba katakan, mengetahui bahwa ketergantungan Anda ada saat startup adalah masalah terkecil Anda, menanganinya dengan baik ketika hilang lebih penting, dan harus menyelesaikan yang pertama juga.

Tapi sekali lagi, ini adalah pemikiran saya tentang masalah ini, dan saya bisa saja salah;)

Ya, tidak masuk akal untuk layanan mikro, tetapi tidak semuanya adalah layanan mikro, saya menjalankan Hadoop dalam sebuah wadah. Docker bukan hanya untuk layanan mikro. Seperti yang saya katakan, ini bagus untuk lingkungan yang saya kendalikan, tetapi dalam hal-hal yang tidak saya kendalikan, itu memerlukan pembungkusan titik masuk layanan. Itu baru saja diselesaikan dengan depend_on dengan healtcheck, saya rasa akan sangat bagus untuk memilikinya di Swarm juga. Memulai kembali secara kontinyu hanyalah pilihan pria malas.

Teman-teman,

Saya pikir ada semacam kesalahpahaman tentang "toleransi kesalahan" dan semacam "inisialisasi pertama kali".
Setuju bahwa pendekatan tersebut terdengar cukup baik untuk yang pertama, tetapi yang terakhir ini benar-benar menyakitkan.
Saya akan membayangkan bahwa tidak hanya diri saya sendiri, tetapi umumnya seseorang biasanya perlu memulai layanan dalam urutan tertentu karena mereka lebih atau kurang bergantung satu sama lain.

Memiliki restart terus menerus pada fase inisialisasi dan menunggu layanan di beberapa titik mulai dalam urutan yang tepat dengan sendirinya seperti mimpi buruk - seseorang tidak dapat merencanakan "waktu henti" untuk proses startup jika yang lebih buruk terjadi. Tidak hanya yang lebih buruk, tetapi kadang-kadang ada seperti mengatakan "pemeliharaan" waktu ketika sesuatu perlu diubah dan tidak ada yang dapat memprediksi berapa banyak waktu yang dibutuhkan untuk sistem untuk benar-benar memulai, karena layanan yang berbeda dimulai ulang oleh gerombolan berulang kali lagi menunggu pesanan yang tepat.
Saya sudah mencoba dan menunggu untuk melihat bagaimana hasilnya dengan 7 kontainer dan selama 20 menit _swarm_ masih belum menemukan jawabannya dan seluruh layanan masih turun.
Jadi seseorang bahkan tidak dapat menyatakan berapa banyak waktu yang dibutuhkan untuk mengembalikan dan memulihkan seluruh infrastruktur karena benar-benar tidak diketahui berapa lama waktu yang dibutuhkan _initial startup_.
Kedengarannya tidak masuk akal bagiku.

Saya tidak berpikir saya bisa cukup masuk ke dalam "produksi" tanpa prediktabilitas seperti itu meskipun itu seharusnya jarang terjadi (sepenuhnya turun) - yang terbaik tidak pernah terjadi.
Tetapi jika itu masih terjadi, saya akan berada di tempat dan akan ditantang untuk memulihkan ASAP dan tepat pada waktu dan tekanan itu saya sama sekali tidak tahu berapa lama kontainer saya akan mulai hanya karena mereka terus memulai ulang sendiri selama _startup._

@ Ozlatkov Ini seharusnya diposting di pelacak masalah buruh pelabuhan / buruh pelabuhan, bukan di sini.

@ shin- Terima kasih! Saya telah memindahkannya ke pelacak buruh pelabuhan / buruh pelabuhan:

https://github.com/docker/docker/issues/31333

Saya pikir sangat buruk bahwa tim Docker menganggap Docker Swarm digunakan. Compose seharusnya menjadi alat mandiri yang berfungsi sepenuhnya.

Namun, kami banyak menggunakan Docker Compose dalam pipeline pengujian kami dan PENGHAPUSAN fitur yang mendasar (tanpa memberikan alternatif yang bisa diterapkan) benar-benar memiliki efek negatif yang dramatis pada pengguna Anda.

Saat ini saya sedang meninjau PR yang sangat jelek dari anggota tim saya di mana mereka mencoba untuk menemukan semua jenis solusi untuk ini (karena kami sangat bergantung pada fungsi ini), termasuk tetap menggunakan Compose 2.X untuk selamanya.

Docker seharusnya membantu kita mencapai tujuan kita, bukan membuatnya lebih sulit dengan menghapus fitur penting yang sudah diandalkan banyak tim.

Harap pertimbangkan kembali untuk memindahkan semua ini ke Docker Compose 3.

Sangat dihargai.

Untuk ke-100 kalinya sekarang: Tidak ada alasan untuk menggunakan format v3 jika Anda tidak berniat menggunakan layanan swarm.

Apakah itu berarti tim berkomitmen untuk mendukung format 2.X bagi mereka yang menggunakan compose sebagai alat pengembangan mandiri?

Persis pertanyaan saya: apakah tim Tulis berkomitmen untuk mendukung format v2 selamanya?

Kami tidak dapat melakukan standarisasi pada Docker Compose jika format v2 dijadwalkan untuk tidak digunakan lagi kapan saja.

Saya merasa seperti ini memaksa semua kontainer ke dalam pola init container , menghapus kebijakan restart buruh pelabuhan dan menciptakan pendekatan hacky untuk urutan startup. Haruskah diasumsikan bahwa> = v3 dari compose akan bergerak ke arah ini untuk fokus pada stack dan membuat bundel aplikasi? Dan jika itu benar, dapatkah Anda mengarahkan saya ke cara menjaga urutan startup di tumpukan buruh pelabuhan? Apakah wait-for-it.sh atau dockerize pendekatan di sana?

Apa deklaratif yang setara dengan docker-compose.yml untuk tumpukan?

Hai teman-teman, apa praktik terbaik jika saya berniat menggunakan tumpukan buruh pelabuhan dan menghapus penulisan buruh pelabuhan?

Ini tampaknya menjadi solusinya, tetapi memiliki semacam skrip hacky ke wadah init sepertinya bukan praktik yang baik. Melakukannya?

Terima kasih.

@mustafaakin Terima kasih atas downvote Anda! Sangat membantu ❤️

@VinceOPS Saya tidak yakin tentang "praktik terbaik" tetapi saya telah menggunakan pemeriksaan kesehatan dan restart: always jadi hanya siklus sampai berhasil ¯ \ _ (ツ) _ / ¯

@hutchic Tapi seperti yang disebutkan dalam percakapan di atas, itu tidak bisa memiliki tanggal berakhir, semacam

Mengapa tim buruh pelabuhan menghapus fitur ini di versi3 dan menolak untuk menambahkannya?

@ tianhao-au lihat pembahasannya di https://github.com/moby/moby/issues/31333 (dan https://github.com/moby/moby/issues/31333#issuecomment-409143581)

Untuk menulis, saya juga meninggalkan saran di https://github.com/moby/moby/issues/31333#issuecomment -333265696 (punya x-depends_on )

Perubahan fitur ini benar-benar mengapa saya tidak lagi menggunakan docker-compose. Jika saya menggunakan buruh pelabuhan dalam produksi dan buruh pelabuhan-menulis secara lokal untuk lingkungan dev, saya sekarang diharuskan untuk membuat wadah buruh pelabuhan saya berperilaku sangat berbeda di dev daripada di produksi. Dalam produksi, saya mengandalkan sistem orkestrasi untuk memastikan kesehatan dan ketertiban penerapan saya. Di negeri pengembang itu orkestrasi dilakukan dengan buruh pelabuhan-menulis. Sekarang saya sedang menulis sekumpulan skrip yang rusak untuk memeriksa kesehatan hal-hal untuk mengatur sistem saya. Jika saya akan melakukan itu mengapa tidak menulis beberapa golang untuk mengelola buruh pelabuhan saya dan menyelesaikannya. Sedikit kecewa karena terjatuh. Hanya 2p saya

Mencoba menggunakan versi docker-compose terbaru untuk membuat segalanya lebih tahan masa depan dan tersandung pada masalah ini. Ini menyedihkan.