@jmmills Tidak bisakah Anda memulai wadah Anda seperti: "docker-compose scale worker=5" dan layanan itu akan dimulai dengan 5?

@aanm Ya, tapi saya pikir fungsionalitas itu harus dicerminkan sebagai default dalam definisi layanan. Mungkin saya memiliki sekumpulan pekerja minimal yang harus selalu berjalan dan saya ingin itu dinyatakan dengan jelas sebagai default.

@ @aanm Apakah Anda berharap bahwa docker-compose up harus mempertimbangkan parameter scale ? Satu-satunya masalah dengan ini yang saya lihat adalah bahwa kami memperkenalkan parameter ke dalam konfigurasi deklaratif yang TIDAK kompatibel dengan konsep Docker/Docker API yang mendasarinya tetapi sangat spesifik untuk Docker Compose.

Jika kita melakukan ini ke depan; Saya akan menyarankan sesuatu seperti:

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

Di mana $<parameter> menunjukkan hal khusus Docker Compose.

Kami telah bolak-balik tentang apakah scale termasuk dalam YAML; sudah ada PR untuk menambahkannya sebelumnya (#630). Saya masih berpendapat bahwa kebanyakan orang tidak boleh memasukkan nomor skala dalam konfigurasi mereka, karena membuatnya kurang portabel, tetapi saya memahami kasus penggunaan untuk melakukannya.

Sekarang kami memiliki cara dasar untuk menambah file Compose dengan extends (dan semoga yang lebih baik segera - #1380, #758), kekhawatiran yang saya ajukan di https://github.com/docker/compose /pull/630#issuecomment -69210279 mungkin tidak terlalu bermasalah.

Saya ingin menetapkan scale=0 di yml saya untuk layanan terkait pengujian yang biasanya tidak ingin saya mulai. Saya hanya ingin membuat layanan tersebut secara eksplisit dengan docker-compose run atau scale eksplisit.

@jamshid Saya sering menginginkan itu, definisi yang mengatur lingkungan tetapi tidak berjalan secara default. Saya telah diturunkan untuk membuat gambar dasar (yang juga akan dibantu oleh skala nol/tanpa operasi) di mana saya menjalankan pengujian unit saya (melalui docker run ), dan kemudian komposisi wadah saya menggunakan gambar dasar.

Sesuatu seperti ini tampaknya cukup berguna untuk konfigurasi dev

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmills Bagaimana dengan parameter/kunci enabled dalam file YAML per layanan? Sehingga Anda dapat menonaktifkan/mengaktifkan layanan?

@prologic Mengapa melakukan itu ketika parameter "skala" akan menyelesaikan kedua kebutuhan?
Jika Anda ingin membayangkan proses/wadah yang berjalan sebagai turunan dari sebuah kelas, seseorang bahkan dapat menamakannya instances

@jmmills Saya hanya mencoba menemukan _solusi_ untuk kasus penggunaan Anda yang tidak melibatkan pemecahan docker-compose saat ini. Saya cenderung berpikir scale=0 sepertinya tidak pas dan saya berpikir dua kali tentang apakah scale=X bahkan harus menjadi bagian dari Compose itu sendiri.

Menurut saya skala (atau jumlah salinan) adalah bagian dari komposisi layanan, sehingga harus dimasukkan dalam compose.

Yah saya pikir kita memiliki kunci scale=0 atau disabled .

:+1: tentang memiliki kemampuan menyetel ukuran default scale untuk sebuah instance. Dan saya setuju, begitu skala masuk, tidak perlu kunci disabled , karena Anda cukup menyetel skala ke 0.

+1

Juga, kasus penggunaan lain: Bagaimana jika saya ingin menskalakan jumlah kontainer tetapi tidak ingin mem-background semua layanan, atau harus melompat ke terminal lain (atau proses) dan mengatur nomor skala saya...
misalnya:

$ docker-compose up && docker scale thing=4

Tidak berfungsi karena naik tidak keluar.
Tetapi jika file komposisi saya mengatur skala wadah saya ...

$ docker-compose up

Menjadi DWIM.

Saya tidak yakin bahwa saya benar-benar menyukai ini; tiba-tiba up mengambil dua kemampuan:

• Bawa wadah apa pun yang tidak memiliki parameter scale .
• Bawa wadah apa pun yang memiliki scale=0 .

Kami sekarang benar-benar menyalahgunakan perintah "naik". "Skala" juga memiliki arti baru karena sekarang melakukan dua hal:

• skala wadah naik/turun
• Nonaktifkan kontainer/layanan dengan cara ` scale=0

Mengapa memunculkan wadah dengan scale=0 ?
Build akan membuat gambar dengan scale=0 , sehingga memfasilitasi kebutuhan gambar dasar.

Saya _bisa saja salah_ tetapi membaca komentar terakhir Anda itu menyiratkan bahwa :)

Biarkan saya menguraikan:

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

Sekarang, perilaku yang diharapkan: docker-compose build membuat wadah apa pun dengan "build" (apakah compose menarik gambar eksternal pada build? tidak ingat), docker-compose up akan menjalankan apa pun dengan skala positif (defaultnya adalah 1), docker-compose run test_harness akan membangun "base_thing" jika diperlukan dan menjalankan satu perintah saya. Mengerti? :)

Sunting: docker-compose up akan menjalankan 1 "thing" dan 4 "workers_for_thing"

Oke terima kasih; contoh Anda lebih masuk akal dan sedikit lebih jelas tentang maksud scale=0

Saya pikir docker-compose "menarik" gambar pada up / run .

Saya perlu membuat resep yang menunjukkan jumlah contoh (skala), untuk pengujian, produksi, qa, dll.

+1 untuk scale=X . Ini akan sangat membantu.
Dan +1 untuk komentar @jmmills dengan deskripsi konfigurasi dan hasil yang diharapkan.

Ya! untuk scale=x . Menginisialisasi satu set wadah pasti akan membantu mengidentifikasi kondisi balapan potensial saat menyiapkan konfigurasi klaster.

+1 untuk scale=x (termasuk scale=0 untuk menonaktifkan layanan untuk docker-compose up )

+1 untuk scale=x .

x adalah NaN, saya akan mengusulkan -1 sebagai gantinya.

+1 untuk skala=x.

+1

+1

Bagaimana kalau kita berhenti dengan +1?

Memberi +1 berguna untuk melihat tingkat ketertarikan suatu fitur.

@shofetim Saya tahu cara yang lebih baik untuk melakukan hal itu: menerapkan fitur yang dimaksud dan mengirimkan permintaan tarik...

Memberi +1 juga merupakan cara yang baik untuk melihat orang-orang menyetujui solusi yang diusulkan. Perilakunya cukup umum di github. Mengklik tombol berhenti berlangganan dari notifikasi akan mematikannya jika itu masalah.

Yah, sepertinya orang-orang seperti ini. Ada item serupa di backlog penulisan (tersisa dari Gambar), saya cukup yakin saya telah mengomentarinya di beberapa titik. Saya akan mencoba dan menindaklanjutinya nanti malam.
Saya di PuppetCon hampir sepanjang minggu ini, jadi semoga itu memberi saya waktu untuk meretas - saya akan melihat apakah saya bisa menulis ini.

Berikut ini adalah solusi untuk kasus penggunaan "skala = 0":

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkel ya, saya pernah melakukan hal serupa di masa lalu.

Saat ini saya sedang berusaha membiasakan diri dengan basis kode penulisan, setelah saya tahu di mana semua hal untuk penulisan, saya akan meretas PR untuk parameter konfigurasi skala.
Sepertinya tidak akan terlalu sulit, ada metode scale untuk proyek yang merupakan backend untuk antarmuka cli, jadi yang harus saya lakukan hanyalah menambahkan "skala" ke skema bidang, pastikan jika ada untuk memanggilnya setelah pembuatan wadah ... lalu pastikan itu tidak menjalankan wadah jika disetel ke nol.

Sebenarnya ada PR lama yang terbuka untuk ini: #630.

Masalahnya adalah bahwa skala adalah masalah operasional, itu bukan bagian dari definisi aplikasi, sehingga tidak terlalu cocok dengan file penulisan.

Akan menyenangkan untuk mendukung konfigurasi untuk tingkat skala default, tetapi saya tidak berpikir file penulisan adalah tempat yang tepat untuk itu.

Kasus scale: 0 seharusnya sudah ditangani oleh #1754. Wadah "no-op" hanya dapat memiliki perintah yang langsung keluar (echo, true, dll). Kasus untuk menginginkan scale: 0 biasanya salah satu dari dua: wadah volume data, atau "tugas adhoc/admin".

Tidak lama lagi kita seharusnya tidak memerlukan penampung volume data karena volume mendapatkan titik akhir API baru, dan kita akan dapat menentukan volume tanpa memerlukan penampung.

Tugas administratif lebih baik ditangani dengan #2051. Anda dapat mendefinisikan admin.yml yang memperluas inti docker-compose.yml dan memungkinkan Anda untuk menautkan tugas administratif Anda ke "komposisi inti" tanpa mengacaukan definisi masing-masing.

Kedua perubahan ini ada di master sekarang dan akan tersedia dalam rilis 1.5.0 (yang sudah dekat).

Sehingga hanya menyisakan kasus keinginan untuk menskalakan layanan ke> 1 secara default. Sudah cukup mudah untuk membuat skrip seperti ini, tetapi bisa memasukkannya ke dalam file konfigurasi akan tetap menyenangkan. Saya pikir kita akan mengeksplorasi ide konfigurasi terpisah di #745. Menurut pendapat saya, konfigurasi baru ini akan menjadi tempat yang baik untuk hal-hal yang bukan bagian dari definisi aplikasi (nama proyek, nama jaringan default, skala default, dll).

Dengan hormat saya tidak setuju dengan skala yang hanya menjadi perhatian operasional. Aplikasi dapat peduli tentang jumlah minimum layanan yang berjalan.
Sejauh wadah tanpa operasi, rasanya sulit untuk benar-benar menjalankan wadah ketika tujuan wadah itu memicu gambar dasar untuk dibangun di mana wadah lain digunakan untuk bidang image .

Aplikasi dapat peduli tentang jumlah minimum layanan yang berjalan.

Bisakah Anda memberikan contoh kasus ini?

Sejauh wadah tanpa operasi, rasanya sulit untuk benar-benar menjalankan wadah ketika tujuan wadah itu memicu gambar dasar untuk dibangun di mana wadah lain digunakan untuk bidang gambar mereka

Apakah ada alasan mengapa gambar dasar harus menjadi bagian dari bangunan yang sama? Seperti yang saya sebutkan di # 1455, penulisan pada dasarnya bukan alat "pembuat buruh pelabuhan". Tujuannya adalah untuk menyediakan komposisi wadah saat runtime. Mencoba mendukung setiap skenario build yang mungkin sangat meningkatkan cakupan penulisan dan mengalihkan fokus dari komposisi container. Akan sulit bahkan untuk alat yang dirancang untuk membangun gambar untuk mendukung setiap permintaan ini. Saya pikir arah yang lebih baik adalah menjaga kompleksitas build dari compose, dan membiarkan pengguna menukar alat build yang sesuai sebagai ganti docker-compose build .

Kasus penggunaan yang saya pedulikan adalah scale=0 (mungkin abstract=true akan menjadi deskriptor yang lebih baik). Saya ingin berbagi gambar dan variabel lingkungan di antara perintah yang berbeda. Secara khusus saya ingin satu server web berjalan dan satu server pekerjaan latar belakang berjalan, keduanya dengan kode yang sama dan keduanya dengan variabel lingkungan yang sama.

@wkonkel menggunakan contoh Anda, saya kira ini juga akan berhasil?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

Anda berdagang dengan layanan abstrak dengan penggantian tanpa operasi command tanpa abstrak dengan penggantian tanpa operasi pada ports . Apakah itu terdengar benar?

1988 terkait dengan layanan abstrak.

@dnephin Ya, itu berhasil dalam kasus saya.

Sebenarnya, saya mengambilnya kembali ... Saya baru saja mencobanya dengan docker-compose-1.4.2 dan tampaknya "ports: []" tidak menimpa induknya, jadi app_worker gagal memulai dengan "port sudah dialokasikan ".

@dnephin Utas mungkin memiliki penjelasan yang lebih baik, tetapi saya akan mencoba mengartikulasikannya di sini.

Hal pertama yang terlintas dalam pikiran adalah sistem pekerjaan di mana wadah terpisah yang menjalankan kode yang sama dapat dimodelkan seperti jenis layanan parent->fork()->child pool di mana konfigurasi aplikasi default menginginkan jumlah minimum pekerja untuk konkurensi.

Inspirasi saya untuk ini berasal dari aplikasi yang menggunakan pekerja RQ yang dilampirkan ke antrean berbeda yang membagikan gambar dasar yang berisi paket python saya (kode pekerja), tetapi menjalankan beberapa instance untuk setiap antrean. Ketersediaan minimum konkurensi adalah persyaratan aplikasi karena pekerjaan yang berjalan lama.

Saya hanya berpikir bahwa memiliki perintah no-op sepertinya membuang-buang sumber daya hanya untuk mendapatkan gambar dasar bersama yang dibangun dengan cara yang sama seperti tumpukan aplikasi lainnya. Anda berakhir dengan loop sementara/tidur hanya untuk gambar dasar, yang merupakan solusi yang keren, tetapi sepertinya bukan cara intuitif untuk mencapai ini. Belum lagi meninggalkan item di pohon proses kami tanpa fungsi runtime.

Jika docker-compose benar-benar tidak menyeberang ke domain kodifikasi hubungan membangun gambar, maka mungkin opsi build harus dihilangkan, dan beberapa sistem definisi build lainnya harus dibuat sehingga saya dapat menentukan target build untuk membangun gambar dasar , dan kemudian gambar lain yang menggunakan basis itu dengan beberapa artefak/konfigurasi yang dimodifikasi, dan dalam urutan yang benar?

Atau mungkin, saya hanya terlalu berpendirian dan harus membungkus perintah penulisan buruh pelabuhan saya dalam skrip Shell untuk memulai layanan saya dengan skala, dan mendefinisikan semua gambar saya sebagai membuat target dengan dependensi.

Saya hanya berpikir bahwa memiliki perintah no-op sepertinya membuang-buang sumber daya hanya untuk mendapatkan gambar dasar bersama yang dibangun dengan cara yang sama seperti tumpukan aplikasi lainnya.

Dengan #1754 (di rilis berikutnya) itu tidak diperlukan lagi. Sebuah layanan dapat keluar dan tidak akan menghentikan layanan lainnya. Jadi Anda dapat memiliki pangkalan hanya keluar dan tidak khawatir tentang hal itu.

@dnephin Keren, jadi apakah Anda akan memberikan link ke wadah dasar/perantara itu untuk memastikannya dibangun terlebih dahulu?

@dnephin : Saya memiliki pelari CI yang setara dengan docker compose up . Saya ingin lingkungan pengujian saya berjalan dengan beberapa versi layanan (yaitu, skala). Saya bisa menyalin seluruh blok konfigurasi tetapi ini akan melibatkan pengulangan sendiri. Dalam hal ini, ini bukan "hanya masalah operasional", itu adalah sesuatu yang saya butuhkan di lingkungan pengembangan saya saat saya mengembangkan aplikasi berkerumun, yang saat ini sepenuhnya menggambarkan file penulisan. Saat ini saya harus memiliki beberapa konfigurasi skala out-of-band dan kemudian entah bagaimana memanggil docker-compose scale , saya kira, tetapi ini tampaknya tidak ideal dan memperkenalkan peluang lebih lanjut untuk kegagalan dan balap.

Dalam kasus produksi, Anda mungkin ingin memberi bintang pada layanan Anda dengan skala minimum. Katakanlah misalnya Anda bermigrasi dari satu cluster ke cluster lain, dan biarkan beberapa bagian sulit dari migrasi sebagai menyalin data untuk kesederhanaan contoh; dan Anda benar-benar harus mulai berurusan dengan beberapa lalu lintas dari awal sehingga Anda perlu menggunakan dengan komposisi buruh pelabuhan setidaknya (n) contoh dari beberapa layanan, katakanlah web.

Memiliki skala di bawah layanan pada file konfigurasi akan benar-benar menanganinya. Ini juga merupakan use case kegunaan karena jika use case sebenarnya mengekspos persyaratan untuk memiliki setidaknya (n) instance dari beberapa runnign layanan dan bukan hanya satu di titik awal.

Dari sudut pandang saya, skala sebenarnya merupakan parameter penentu topologi dan komposisi.

@dnephin

Bisakah Anda memberikan contoh kasus ini?

Consul, MariaDB Master-Master atau aplikasi terdistribusi lainnya di Swarm benar-benar harus memiliki setidaknya 3 node dalam cluster agar dapat diandalkan. Pasti ada kasus penggunaan untuk sejumlah layanan yang tersedia dalam file konfigurasi, saya tidak mengerti mengapa Anda begitu menentangnya. Besar :+1: dari saya disini.

Saya tidak menentang cara untuk mengonfigurasi skala, saya hanya tidak berpikir itu termasuk dalam file penulisan karena statusnya berubah secara independen dari file penulisan.

Ambil contoh ini yang mengasumsikan kita menambahkan beberapa konfigurasi skala ke file penulisan:

1. Saya menetapkan skala awal 3 untuk layanan
2. Saya menjalankan docker-compose up -d , skala layanan saya menjadi 3
3. Saya menjalankan docker-compose scale service=4
4. Saya membuat beberapa perubahan dan menerapkan ulang dengan docker-compose up -d .. Apa yang terjadi? Apakah itu turun-skala ke 3 lagi? Apakah itu mengabaikan skala sepenuhnya sekarang?

Tak satu pun dari skenario ini terdengar bagus atau sesuai, dan ini hanyalah contoh sepele yang mengabaikan kegagalan instan (yang membuatnya semakin rumit).

Jika ingin ditambahkan ke file penulisan, saya pikir kami ingin menghapus perintah scale , sehingga mereka tidak dapat bertentangan.

Contoh yang Anda berikan adalah contoh kebutuhan operasional. Anda tidak memerlukan banyak master untuk menjalankan aplikasi, Anda memerlukannya untuk keandalan (operasi) layanan. Dan Anda masih dapat mencapainya dengan scale db=x .

Menggunakan contoh yang diberikan di atas oleh @dnephin :

Pertama saya pikir perintah skala juga naif, karena Anda tidak dapat mengetahui apakah Anda akan meningkatkan atau menurunkan layanan, memiliki dua perintah diff untuk menjelaskan maksud peningkatan atau penurunan dengan hanya memberi tahu berapa banyak layanan yang dilakukan Anda ingin membuat atau menghapus masing-masing, akan jauh lebih baik.

Jawaban atas pertanyaan yang diajukan oleh @dnephin adalah saya berharap banyak layanan/wadah yang berjalan seperti sebelum modifikasi.

Compose adalah alat stateless yang tidak mengetahui atau memantau layanan/wadah yang digunakan docker api untuk membantu Ops mengatur dan di sana saya pikir masalahnya terletak, compose dirancang untuk menjadi alat bantuan bukan layanan orkestrasi penuh, dan sekarang kami membutuhkan yang itu, kami memiliki mesin yang berjalan dengan baik, kami memiliki mesin untuk disediakan dan kami memiliki swarm untuk menggabungkan semuanya ke dalam sebuah cluster tetapi kami membocorkan layanan/alat orkestrasi nyata yang memberi kami fleksibilitas untuk mengonfigurasi dan untuk mengelola layanan/wadah yang digunakan seperti yang dilakukan k8s. Saat ini menulis adalah hal yang sangat mirip dengan itu tetapi jika tidak di masa depan proyek ini berkembang menjadi sesuatu yang lebih besar, pemikiran terbaik adalah dari pengembang dan pengelola resmi untuk memberi tahu tentang hal itu sehingga kami dapat mencari tahu yang lain. alat yang bisa melakukannya.

Secara pribadi saya pikir akan lebih baik untuk mengembangkan komposisi karena ini adalah alat yang hebat dan terkenal bagi kita semua.

Saya akan senang melihat ini: docker-compose > docker compose .
Tidak yakin tentang alat lainnya, tetapi untuk ini akan sangat menyenangkan untuk memiliki integrasi stateful dengan mesin. Maaf untuk sedikit komentar di luar topik.

Saya telah membuat #2496 untuk proposal saya menghapus perintah skala dan menggantinya dengan opsi skala (dari posting di atas). Umpan balik pada proposal ini akan sangat bagus.

@dnephin dengan

Sekali lagi kami kehilangan poin bahwa semua skenario ini berasal dari poin yang menulis adalah alat tanpa kewarganegaraan dan dari itu ia tidak dapat mengontrol status layanan dan berapa banyak dari mereka di beberapa titik.

Skenario yang Anda sebutkan dalam proposal baru akan dengan mudah diselesaikan dengan layanan/alat lengkap baru-compose.

+1

+1

+1

@dnephin Bukankah perilakunya akan sama jika Anda melakukannya:

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

Bukankah itu lebih merupakan masalah dengan bagaimana skala penulisan tetap ada secara internal.

Itulah masalahnya, "Tulis aplikasi" tidak memiliki kewarganegaraan. Satu-satunya status ada di 1) file penulisan, dan 2) label wadah buruh pelabuhan yang dikelola oleh mesin.

File penulisan hanya diedit oleh manusia, bukan oleh Compose. Akan berantakan untuk mencoba dan menulis yaml dengan komentar, urutan, dan struktur yang sama. Itu tidak didukung oleh pyyaml, dan itu bukan sesuatu yang benar-benar ingin kami lakukan.

Mesin buruh pelabuhan tidak mengetahui skala, sehingga tidak dapat menyimpan status itu. Itu mungkin dengan perubahan arsitektur yang jauh lebih besar, tetapi itu agak di luar cakupan masalah ini.

Untuk saat ini opsi kami pada dasarnya hanya menyimpan skala sebagai opsi baris perintah, atau memindahkannya ke file penulisan, tetapi seperti yang saya jelaskan di #2496 saya pikir memiliki keduanya membingungkan dan mengarah ke perilaku yang salah.

up && scale && up sebenarnya melakukan hal yang benar sekarang. up akan membuat ulang semua wadah, dan karena tidak ada nilai skala dalam konfigurasi, tidak ada kebingungan tentang skala yang diinginkan. Itu sudah diatur oleh perintah skala, dan dilacak oleh label wadah.

@dnephin Saya pikir saya setuju dengan apa yang Anda katakan, [saya mungkin salah dalam asumsi ini] bahwa apa yang sebenarnya Anda pertanyakan adalah _jika_ jumlah contoh komponen sebenarnya menyangkut komposisi layanan (pengelompokan wadah menjalankan wadah komponen yang berbeda). Saya akan mengatakan bahwa saat ini menangani masalah itu, hanya dengan peringatan kurangnya paritas antara cli dan definisi komposisi (yaml).

Jika ruang lingkup tanggung jawab ditentukan bahwa skala bukan urusan komposisi maka skala harus dihapus sebagai opsi cli (mungkin membuat marah banyak pengguna), atau jika ditentukan bahwa skala adalah urusan komposisi layanan bahwa harus ada keseimbangan antara cli dan yaml dengan dukungan tambahan dari instance minimum untuk memperhitungkan instance berkerumun yang memerlukan N+1.

Setuju dengan @jmmills Terutama saat menjalankan klaster wadah data, ketika ketersediaan dan replikasi berjalan beriringan, minimal scale adalah bagian dari aplikasi: tanpa skala yang tepat, aplikasi mungkin tidak berfungsi

+1

+1

+1

Saat ini saya perlu menyatakan hal-hal seperti itu:

selenium-chrome1:
...
selenium-chrome2:
...

Akan menyenangkan:
selenium-krom:
skala: 2

+1

persis apa yang dikatakan @caioquirino . +1

docker-compose up harus memunculkan lingkungan kerja tanpa memerlukan pekerjaan lain. Satu-satunya cara untuk memunculkan layanan yang membutuhkan banyak node adalah dengan menggunakan pola yang disebutkan @caioquirino . Mengabaikan pelanggaran KERING di sini, polanya berbau salah ketika Anda kemudian mencoba menggunakan perintah skala untuk menambahkan simpul lain karena tidak jelas 'layanan' mana yang harus diskalakan.

Skala dalam file yml memperbaikinya.

Besar +1, saya juga ingin menggunakan ini untuk mendefinisikan layanan yang skalanya disetel ke 0 pada awalnya.

Sepanjang garis...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

Idenya adalah Anda bisa menggunakan docker-compose.yml yang sama dan transisi mulus dari lingkungan pengembangan ke produksi. Instance consul_master akan secara otomatis bergabung dengan rakit dan menetapkan kuorum dengan melakukan docker-compose scale consul_master=3 . Ini akan sangat keren.

Untuk menanggapi @dnephin...

Ambil contoh ini yang mengasumsikan kita menambahkan beberapa konfigurasi skala ke file penulisan:

1. Saya menetapkan skala awal 3 untuk layanan
2. Saya menjalankan docker-compose up -d, skala layanan saya menjadi 3
3. Saya menjalankan layanan skala penulisan buruh pelabuhan = 4
4. Saya membuat beberapa perubahan dan menerapkan ulang dengan docker-compose up -d.. Apa yang terjadi? Apakah itu turun-skala ke 3 lagi? Apakah itu mengabaikan skala sepenuhnya sekarang?
5. Suka sekali
6. Baik
7. Aku masih bersamamu
8. Saya pikir harus ada beberapa perbedaan antara penerapan yang ada dan penerapan baru sehingga skala kontinuitas dapat dipertahankan untuk penerapan yang ada yang menerima pembaruan berkelanjutan. Penerapan individu akan menyertakan DOCKER_HOST env dll, bersama dengan skala setiap komponen, ID gambar, dan riwayat penerapan ulang. Ini bisa menjadi tempat yang baik untuk menghubungkan ke mekanisme upstack seperti penyebaran berkelanjutan atau penyebaran hijau biru? Saya membayangkan alur kerja siap produksi yang sedikit lebih banyak, jadi Anda cukup terhubung ke DOCKER_HOST yang berbeda dan melakukan docker-compose up -d dan kemudian menyediakan pengait sehingga alat upstack dapat mengelola hal-hal seperti CI dan peluncuran biru/hijau. Mungkin menambahkan sesuatu seperti DOCKER_COMPOSE_ENV={"testing " || "produksi" || "dev"}?

IMHO, setelah "hardcoded" scale , katakan ke 3, itu harus dimulai dengan 3 wadah

Saya pikir banyak kebingungan tentang parameter "skala" vs. perintah "skala" akan dikurangi dengan memberi nama parameter YAML "initial_scale" atau "default_scale". Itu membuatnya cukup jelas bahwa itu hanya nilai yang akan digunakan jika tidak ada semacam penggantian. Itu juga (setidaknya IMHO) tampaknya masuk akal bahwa parameter "initial_scale" ini hanya akan direferensikan ketika docker-compose menampilkan layanan untuk pertama kalinya, dan tidak ketika menjalankan docker-compose up lagi dengan beberapa contoh layanan yang sudah berjalan.

+1 untuk "initial_scale", juga akan secara eksplisit menggambarkan parameter ini sebagai khusus penulisan, karena buruh pelabuhan sendiri tidak memiliki parameter seperti itu.

Ada hal menarik yang terjadi, dalam posting blog https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ di video "48.56 menunjukkan bahwa pada pusat data buruh pelabuhan yang baru dirilis Anda dapat pada titik pembuatan tumpukan benar-benar mengatur berapa banyak contoh wadah yang ingin Anda jalankan Jadi ide ini bukan hal baru bagi tim buruh pelabuhan, semoga dapat dimasukkan dalam rilis penulisan berikutnya

+1

+1

Jutaan masalah dan permintaan skala/initial_count dan seterusnya .. dan masih belum direncanakan.

Sedih melihat proyek yang bagus tetapi orang hanya mencari alasan dan menciptakan masalah baru dan duplikat, menutup masalah dan "melakukan" pekerjaan.

+1

+1

+1

+1

TOLONG HENTIKAN!
JANGAN TAMBAHKAN +1!
HANYA BERLANGGANAN UNTUK MASALAH!

+1 ( @pierrre maaf)

+1 sangat penting ( @pierrre , maaf)

Saya setuju, tetapi saya tidak ingin menerima 100.000 notifikasi untuk "+1" Anda!

/me forks docker compose dan mulai mempelajari basis kode.

Banyak poin valid di atas, sepertinya memiliki parameter default/inital scale dalam file konfigurasi + perintah cli scale akan menangani keduanya. Untuk menambahkan kasus penggunaan dalam mendukung opsi skala awal, pertimbangkan layanan berkerumun di mana kuorum terdiri dari sejumlah X node dan yang sebaliknya tidak boleh beroperasi (misalnya tidak kurang dari 3). Maksud dari docker-compose adalah memiliki deskriptor lengkap dari sistem semacam itu.

Kasus penggunaan saya adalah:

Saya telah memperluas layanan dengan beberapa pengaturan umum untuk memungkinkan lebih sedikit duplikasi. Namun layanan dasar dibuat (saat dijalankan tanpa secara eksplisit menentukan nama layanan) dan kemudian saya mematikannya secara manual. Saya ingin layanan dasar memiliki skala awal 0.

Saya setuju secara umum. Meskipun menurut saya, masalah ini dan masalah terkait/terkait bermuara pada masalah yang sedikit berbeda: up dan scale akhirnya ingin menjadi perintah yang sama.

Mereka terkadang sudah:

• docker-compose up service
• docker-compose scale service=1 .

Dan, jika scale mengekspos semua opsi cli (misalnya --force-recreate ) yang dilakukan up , atau jika up tahu tentang penghitungan, maka pada dasarnya mereka akan melakukannya.

Jika, seperti yang diusulkan oleh masalah ini, direktif "skala awal" ditambahkan ke docker-compose.yml , maka up harus belajar menghitung. Pada titik mana, bukankah up hanya mendukung sintaks penghitungan docker-compose up service=10 (yang dapat menimpa skala apa pun yang ditentukan dalam yaml)?

Ada perbedaan yang ditarik antara "skala awal" dan "skala", yang bisa menjadi domain dari perintah yang berbeda. Tetapi karena up idempoten dan dirancang untuk dijalankan berulang kali tanpa harus mengubah status, saya rasa perbedaan ini tidak ketat. Saya pikir kita harus mempertimbangkan untuk membuat up mengkanibal scale secara langsung.

@mattgiles Saya setuju, ke sanalah saya pergi dengan #2496, namun saya tidak menganggap bahwa service=count dapat ditambahkan ke up . Saya pikir itu mungkin menangani situasi. Satu-satunya masalah yang saya lihat adalah bahwa saat ini up web berarti hanya memunculkan layanan web dan dependensinya. Mencoba melakukan up web=3 harus terus berarti hal yang sama. Yang berarti bahwa tidak ada cara untuk up semuanya dan mengesampingkan hitungan skala sekaligus, tapi itu mungkin baik-baik saja.

Saya akan memperbarui proposal di #2496

@dnephin saya melewatkan proposal yang lebih baru. Luar biasa!

fwiw, saya pikir itu benar-benar intuitif untuk docker-compose up web=3 untuk memunculkan tiga wadah untuk layanan "web", serta dependensi apa pun ... dalam rasio yang ditentukan dalam yaml (per sesuatu seperti scale direktif). Dengan cara itu file penulisan terus mengatur kecuali diganti oleh baris perintah.

Pemanggilan berikutnya dari up dapat dilanjutkan, seperti yang mereka lakukan sekarang, untuk meninggalkan wadah yang ada. Hanya jika skala saat ini lebih kecil dari yang ditentukan dalam yaml maka akan mengubah hitungan agar sejalan dengan skala terlarang. Tidak ada skala yang ditentukan akan terus menyiratkan skala 1.

Hal-hal seperti --force-recreate mungkin juga harus membiarkan jumlah saja jika lebih tinggi dari yang ditentukan dalam yaml, tetapi tetap membuat ulang semua wadah agar sejalan dengan atribut lainnya.

Juga masuk akal bagi saya untuk dapat mematikan wadah, seperti yang saat ini dapat dilakukan dengan scale , dengan memanggil sesuatu seperti docker-compose up web=2 dll.

+1

+1 (hanya untuk mengganggu @pierrre ;))

+1

+1 untuk skala=x.

Terkait dengan ini, saya ingin cara untuk menggambarkan Lajang. scale=1

Keberhasilan apa pun di sini dengan opsi skala

+1

Saya belum melihat sesuatu yang baru tentang ini dari upstream , secara pribadi saya belum memiliki kesempatan untuk melihat apakah saya dapat meretas tambalan untuk itu.

Terima kasih,
Jason Mills

• dikirim dari HP.

Pada 8 Agustus 2016, pukul 17.19, lavvy [email protected] menulis:

Keberhasilan apa pun di sini dengan opsi skala

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

+1

+1

+1

+1

+1 (untuk mengganggu @pierrre lagi)

+1

Saya ingin mengulangi kasus ini

skala = 0
Berguna untuk pengujian, debug. periksa layanan dll. yang biasanya tidak ingin Anda tampilkan, tetapi Anda ingin didefinisikan - karena layanan tersebut biasanya digunakan dalam konteks layanan lain dalam file.

skala = 1
Karena saya ingin satu-dan-satunya-satu ini - _ever_. Dalam klaster MariaDB, ada kasus di mana saya mungkin hanya ingin satu node dikonfigurasikan dengan mesin penyimpanan tertentu (mis. Spider, ColumnStore, dll.).

skala = n
Karena ada kalanya saya tahu bahwa saya perlu menjalankan layanan 'n', misalnya, klaster MariaDB di mana saya akan selalu memiliki satu Primer (dengan konfigurasinya) dan dua Sekunder (dengan konfigurasi yang berbeda, dari Primer).

Masuk akal bagi saya @alvinr. Defaultnya seharusnya adalah 1.

DISCLAMER: Saya bukan perwakilan dari Marathon atau Mesosphere

Ini adalah contoh lain dari permintaan fitur yang cukup sederhana yang telah ditinggalkan/didorong oleh tim dukungan buruh pelabuhan selama lebih dari setahun. https://github.com/docker/docker/pull/12749 adalah contoh lain. Kubernetes dan Marathon telah memiliki opsi ini selama beberapa waktu sekarang ( "instances": 3 di file marathon.json) dan bahkan mengimplementasikan penskalaan otomatis. Keengganan kelompok pendukung buruh pelabuhan yang telah mendorong saya menjauh dari pusat data buruh pelabuhan & swarm untuk beberapa waktu sekarang.

Kontena juga memiliki ini sebagai instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

Cara lain yang dapat kita lakukan adalah dengan menambahkan bagian scale pada file penulisan versi 2.

Itu tidak akan bercampur dengan opsi docker-only yang digunakan dalam layanan.

Contohnya adalah:

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

Ini dengan kemampuan untuk menentukan scale: 0 berpotensi membunuh dua burung dengan satu batu, yang lainnya adalah https://github.com/docker/compose/issues/1896

Ini sepertinya tidak punya otak.

Saya ingin menggunakan nginx+nodejs+mongodb dengan 3 atau 4 instance nodejs. Setiap kali saya memulai aplikasi.

Jika Anda memiliki opsi baris perintah untuk melakukannya, mengapa tidak di file yml?

skala komposisi docker nodejs=4

Akan melakukan.

Itu mudah. Mereka ingin menempuh rute "orang lain membangunnya dan kami
akan mencoba mendukungnya". Selain buruh pelabuhan dasar, mereka belum membuat
apa pun. Compose adalah produk berbeda yang mereka konsumsi dan sekarang mereka miliki
tidak tahu bagaimana mendukung/memperpanjangnya, itulah sebabnya produk seperti maraton dan
kubernetes lebih populer daripada swarm.

Pada 16 Okt 2016 21:36, "Michael Schwartz" [email protected]
menulis:

Ini sepertinya tidak punya otak.

Saya ingin menggunakan nginx+nodejs+mongodb dengan 3 atau 4 instance nodejs. Setiap
waktu saya memulai aplikasi.

Jika Anda memiliki opsi baris perintah untuk melakukannya, mengapa tidak di file yml?

skala komposisi docker nodejs=4

Akan melakukan.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/1661#issuecomment -254093296,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

Sejujurnya saya sedikit terkejut bahwa ada _any_ pushback pada ini karena tampaknya sangat jelas untuk memiliki ...

@westlakem Semoga Docker untuk MacOS tidak mengalami nasib yang sama, semoga Unikernel tetap bertahan.

Akan menyenangkan untuk memunculkan tumpukan lengkap pada ukuran fungsionalnya sekaligus. Dalam kasus penggunaan kami saat ini, tumpukan layanan harus memiliki "pekerja=16" agar berfungsi dengan baik.

Ini sangat menyebalkan:

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

yang jelas bisa diganti dengan sesuatu seperti:

docker-compose up --abort-on-container-exit --scale workers=16

Sunting: Saya melihat bahwa "Rancher" memiliki sintaks seperti komposisi buruh pelabuhan dan mendukung parameter skala awal: https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

Solusinya adalah dengan menggunakan YAML anchor dan menggabungkan kemampuan dan menduplikasi layanan dalam file docker-compose.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

dll ...

Ini akan sangat berguna!

Ini sangat aneh ini tidak ada...

Saya mungkin akhirnya harus membuat layanan duplikat karena saya malas.

Ini sudah bekerja pada file composer v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json yang akan dan sudah didukung pada docker-compose v1. 10.0-rc1

Penawaran "Layanan" mereka memiliki parameter bawaan. Sangat menyedihkan bahwa sebagai
pelanggan untuk masalah ini, tidak ada seorang pun dari tim pengembangan yang memberi tahu kami bahwa
itu datang dalam produk Layanan, dan seseorang harus membaca catatan RC
untuk 1,10 untuk wawasan apa pun. Di mana perwakilan buruh pelabuhan?

Pada Jum, 6 Jan 2017 jam 06:30, Yasmany Cubela Medina <
[email protected]> menulis:

Ini sudah bekerja pada file composer v3 https://github.com/aanand/
compose-file/blob/master/schema/data/config_schema_v3.0.json yang akan
dan sudah didukung di docker-compose v1.10.0-rc1

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

+1

+1

Hai, saya punya pertanyaan terkait.
Saya pernah bertanya-tanya bahwa docker-compose up dapat mengingat skala yang pernah saya tetapkan.

Misalnya, saya menjalankan docker-compose scale nodejs_web=4 lalu docker-compose down ,
lalu saya mulai lagi docker-compose up , itu akan mulai 4 nodejs_web.

Saya ingin tahu di mana perintah scale menyimpan angka 4?

Docker-compose.yml dapat berupa:

version: '2'
services:
  nodejs_web:
    image: node
    command: node

Saya mendukung proposal @dnephin di #2496
Tolong beri kami fitur dasar ini.

Layanan di versi baru Docker memang menawarkan fitur 'replika'.

Pada Senin, 20 Maret 2017 jam 15:28, selalu ada notifikasi [email protected]
menulis:

Saya mendukung @dnephin https://github.com/dnephin proposal di #2496
https://github.com/docker/compose/issues/2496
Tolong beri kami fitur dasar ini.

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

@westlakem - fitur itu untuk swarm. Ini bukan untuk penskalaan layanan reguler.

Begitu banyak pro, sedikit kontra. Ada apa dengan masalah ini?

Ada proposal yang lebih baru tentang menghapus sepenuhnya perintah skala di https://github.com/docker/compose/issues/2496

Saya benar-benar tidak mengerti mengapa atau mengapa tidak ada opsi initial_scale: 3 dalam file penulisan (saya mengerti mengapa itu tidak bisa hanya scale: 3 )

Diimplementasikan kembali pada 1.13.0. Terima kasih semuanya atas tanggapan dan kesabaran Anda.

@shin- Mengapa ini dianggap ditutup? Dalam mengelola aplikasi skala besar di mana SEMUANYA otomatis & dalam kontrol versi, saya sekarang harus memodifikasi Ansible saya yang mengeksekusi Docker untuk menentukan berapa banyak instance layanan yang akan berjalan.

Ansible harus mengatur semuanya agar Docker dapat berjalan. Docker harus mendefinisikan berapa banyak instance layanan yang dibutuhkan aplikasi. Sekarang tanggung jawab Docker untuk mengetahui inventaris layanan tetapi tanggung jawab Ansible untuk memanggil Docker sehingga tahu berapa banyak kontainer yang harus diputar?

@greenscar Maaf, saya tidak yakin apa masalahnya - apakah Anda tidak senang dengan cara penerapan fitur ini? Jika demikian, dengan cara apa kita dapat membuatnya lebih baik?

Mengapa ini tidak ada di versi 3? Sangat membingungkan karena "deploy.replicas" dan "up" tidak setara, bisa dibilang fitur ini tidak ada di v3.

@cgarciae deploy.replicas memiliki tujuan yang sama dengan scale . Mengapa mereka tidak setara dalam pandangan Anda?

@shin- Jika saya tidak ingin membuat swarm dan hanya menggunakan docker-compose up -d , docker compose memberi tahu saya bahwa itu akan mengabaikan pengaturan "menyebarkan".

@cgarciae Mengapa Anda menggunakan file v3 jika Anda tidak ingin membuat Swarm?

Saya pikir semua orang yang menggunakan buruh pelabuhan mengharapkan parameter skala berfungsi untuk file buruh pelabuhan 2 atau 3. Tidak ada alasan untuk tidak melakukannya dan bahkan dapat menetapkan nilai default untuk deploy.replicas juga. Jika deploy.replicas disetel, maka akan menimpa skala dalam swarm. Apa yang salah dengan gambar ini selain dari apa yang diharapkan semua orang terjadi (dan tentu saja jika Anda tidak menyukainya, tidak perlu menggunakannya di docker-compose.yml Anda)?

Parameter skala yang hilang membuat layanan gagal, karena saya lupa meningkatkannya seperti sebelumnya sejak redeloy terakhir -.- mengapa ini bukan hal yang akan menghemat layanan dan bahkan mungkin hidup tergantung pada apa yang berjalan

Tekan saja masalah ini juga. Tampaknya tidak ada cara untuk menentukan berapa banyak layanan yang harus dimulai dari dalam konfigurasi penulisan buruh pelabuhan? Lebih membingungkan lagi bahwa dokumentasi penulisan buruh pelabuhan memiliki banyak dokumentasi untuk hal-hal yang tidak berfungsi dengan penulisan buruh pelabuhan...

Oh tunggu, jadi jika saya mengubah konfigurasi penulisan buruh pelabuhan saya menjadi version: "2.2" maka saya dapat menggunakan scale: 2 tetapi jika seseorang ingin pergi ke versi yang lebih baru, tidak ada lagi opsi untuk melakukan ini?

Oke, saya melihat masalah "versi" ini tidak terlalu berarti versi telah diangkat, https://github.com/docker/compose/issues/4693

Saya menggunakan v3.6 karena saya memerlukan beberapa konfigurasi yang tidak ada di 2.2. Untuk pengembangan lokal saya tidak menggunakan swarm, tetapi saya ingin mengatur scale=0 ke beberapa wadah di docker-compose.overrides.yml saya. Karena beberapa di antaranya hanya untuk proses build seperti container frontendbuild. Kontainer ini berbagi beberapa volume dengan container lain yang sedang berjalan, tetapi tidak boleh dimulai bersama dengan container lain ini di docker-compose up. Jadi buildcontainer hanya berjalan dengan perintah run. Ya saya dapat mengatur --scale param untuk memanggil docker-compose up, tetapi saya pikir lebih baik untuk menulisnya langsung ke konfigurasi. :)

Terima kasih untuk parameter skala. Saya dapat menggunakannya dalam docker-compose.yml non-produksi sehingga siapa pun dapat menggunakan konfigurasi HA Konsul dan Vault. Parameter skala memudahkan penyediaan konfigurasi HA lokal. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

Dalam hal ini, hanya ditujukan bagi seseorang untuk mencoba Konsul dan Vault dalam konfigurasi HA dan menggunakan DNS Konsul.

Versi docker compose mana yang Anda jalankan? Sejak v3 fitur ini telah dijatuhkan (Dengan drop, maksud saya, tidak pernah diimplementasikan), jadi diabaikan. Lihat https://docs.docker.com/compose/reference/scale/

Saya tidak pernah menggunakan format v3 karena fitur yang hilang. Saya cenderung menggunakan format 2.1 atau 2.2 terendah tergantung pada fitur apa yang saya gunakan.

Sunting: bukan untuk mengatakan saya menghindari format v3. Hanya saja ketika saya pergi untuk menulis file penulisan biasanya hilang apa yang ingin saya gunakan.

Ok, saya kira Anda berbicara tentang docker compose dengan swarm stack, itu sebabnya. Saya tidak pernah mencoba, tetapi aneh untuk berbicara tentang HA dengan komposisi buruh pelabuhan tanpa orkestra dan simpul mutli. Apakah untuk tujuan "poc" atau pengujian? Bagaimanapun, saya tidak pernah mencoba dalam konteks ini

Dalam hal ini, HA hanya mengacu pada cluster konsul dan cluster vault. Ini dimaksudkan sebagai bukti konsep yang tersedia untuk eksperimen dan kemudahan bootstrap. HA tidak merujuk ke docker HA atau bahkan HA multi-mesin. Hanya HA di mana orang yang bereksperimen dapat membunuh salah satu wadah cluster dan melihat bahwa layanan konsul dan/atau vault tidak terpengaruh.