Compose: Tentukan layanan yang tidak dimulai secara default

1 untuk opsi 1

Saya pikir menambahkan layanan yang sebenarnya bukan bagian dari komposisi, tetapi kebetulan perlu menautkan / melampirkannya, adalah pilihan desain yang buruk. Ada beberapa kasus penggunaan lain yang akan diselesaikan dengan mengizinkan beberapa bentuk sintaks include. Memecahkan banyak masalah dengan satu fitur selalu menyenangkan.

Beberapa dari masalah ini (yang berhubungan dengan penampung data saja, # 942, komentar terakhir dari @ cpuguy83) sebenarnya sudah diperbaiki oleh # 1754, saya rasa kita tidak perlu menganggapnya sebagai masalah lagi (setelah 1.5 ).

Kami mengembangkan ekstensi Magento. Untuk melakukan itu, kita membutuhkan cara sederhana untuk menjalankan webstore di tumpukan LAMP. Menulis membuatnya mudah. Tetapi kami juga ingin menjalankan phpunit, berbagai alat analisis statis, pembuat dokumentasi, dll. Faktanya, sebagian besar "layanan" kami hanyalah perintah, seperti docker-compose run --rm phplint . Idealnya, perintah yang tidak memenuhi syarat seperti

docker-compose up -d

hanya akan memulai layanan yang berjalan lama (_services_ sebenarnya), dan tidak akan memicu efek lain seperti phpunit, jika tidak perlu. (Ini juga penting agar tidak memicu hal-hal yang rusak, seperti menjalankan tes Selenium sebelum layanan web aktif.)

Yang benar-benar kami coba lakukan adalah menghilangkan rasa sakit dari pengelolaan lingkungan dari pengembang, bukan menjalankan layanan produksi. Saya tidak tahu apakah komentar @dnephin mewakili arah yang

@kojiromike , tentang apa (1) yang tidak sesuai untuk kasus penggunaan Anda? Apakah ini hanya tentang semantik perintah ( docker-compose run --rm phplint vs. docker-compose --file phplint.yml up )?

Itu docker-compose up -d mencoba untuk 'memulai' phplint dan docker-compose ps melaporkan bahwa phplint 'service' sedang down. Pada kenyataannya, itu bukan wadah layanan, melainkan wadah alat, ia seharusnya tidak memiliki konsep naik / turun. Menurut pemahaman saya, wadah alat dipeluk oleh buruh pelabuhan (begitulah cara Anda menjalankan sesuatu seperti redis-cli, jelas bukan 'layanan') dan sementara saya lebih sering menggunakannya dalam pengembangan, saya pikir mereka juga memiliki tempat untuk produksi; seperti mengapa mengatakan awk diinstal pada mesin produksi atau dalam wadah, mengapa tidak menjalankannya melalui wadah dengan tautan untuk mendapatkan perilaku yang dapat diprediksi darinya.

: +1: Saya secara rutin mendapati diri saya ingin membuat wadah tests bersama layanan saya yang lain untuk merangkum pengujian unit yang sedang berjalan. "Solusi" saya adalah mengatur perintah ke "/ bin / true" dan menjalankan wadah dengan perintah uji unit yang ditentukan pada CLI. Mampu menentukan wadah mana yang harus dimulai dari up waktu akan sangat bagus!

(btw, kerja bagus di sekitar, teman-teman)

cc @jameyorio

@ryneeverett Semantik adalah salah satu bagian darinya. Ini masalah pendokumentasian diri dan kemudahan ditemukan. Saat ini, kami memberi tahu pengembang docker-compose run --rm foo bar . Kami mengundang mereka untuk membuat fungsi shell atau alias, tetapi kami tidak mempertahankan alias / rcfile standar untuk proyek. (Kami tidak ingin menstandarisasi hal-hal di luar container; kami ingin menggunakan Docker _to_ standardize.) Menambahkan file baru untuk beberapa perintah akan menciptakan hierarki kepentingan: File docker-compose.yml menjadi file "default" untuk yang penting. hal-hal, dan file "lainnya" menjadi kurang penting.

Hal lainnya adalah menjaga hubungan antar layanan menjadi lebih berat. Hanya karena kita ingin sesuatu tidak berjalan secara default tidak berarti itu tidak menggunakan link atau volume dari layanan yang sudah berjalan lama. extends sebenarnya tidak menyediakan semua fasilitas yang kita perlukan untuk menghubungkan layanan ke "perintah" (layanan sekali jalan). Bahkan jika ya, jika kita harus menggunakan beberapa file yaml, kita akan dipaksa untuk menggunakan extends mana kita tidak perlu melakukannya.

extends sebenarnya tidak menyediakan semua fasilitas yang kita perlukan untuk menghubungkan layanan ke "perintah" (layanan sekali jalan). Bahkan jika ya, jika kita harus menggunakan beberapa file yaml, kita akan dipaksa untuk menggunakan extends di tempat yang tidak kita perlukan.

@ Kojiromike Itulah yang saya duga. Saya ingin tahu apakah Anda akan puas dengan peningkatan extends dukungan + beberapa cara untuk melakukan sub-perintah (yang secara fungsional identik dengan extends ) dalam satu docker-compose.yml . Tapi mungkin yang terakhir sama dengan (4).

2) Tambahkan opsi ke layanan agar tidak dimulai secara default

Saya memilih Opsi 2. misalnya sesuatu seperti perintah start: false . Keuntungannya adalah kami menghindari kebutuhan untuk beberapa file compose.yml atau file konfigurasi tambahan, Anda cukup membaca satu compose.yml untuk merasakan keseluruhan tumpukan aplikasi.

Saya pikir solusi yang kami usulkan untuk https://github.com/docker/compose/issues/1987#issuecomment -139632238 akan menangani ini. Layanan "admin" dapat didefinisikan ke dalam konfigurasi terpisah, dan ditambahkan dengan -f saat perintah admin perlu dijalankan terhadap komposisi.

@dnephin Solusi di # 1987 (komentar) _does_ menangani "layanan admin", tetapi _tidak_ menangani "wadah hanya data", bukan? Anda masih harus menggunakan solusi command: /bin/true .

Anda seharusnya tidak memerlukan penampung khusus data dengan tulis karena tulis akan menangani pertukaran volume ke penampung yang dibuat ulang untuk Anda.

@ cpuguy83 Pada contoh berikut, penampung data tidak terlalu diperlukan, tetapi jika saya ingin mengubah volume, saya hanya perlu melihat satu tempat yang ditentukan.

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

Namun, saya setuju bahwa ini adalah kasus sudut dan menambahkan sintaks tambahan mungkin tidak sepadan. Saya hanya mengatakan bahwa solusi yang diusulkan tidak menangani kasus ini.

Benar, beberapa perintah masih diperlukan untuk volume data, jadi Anda harus menggunakan gambar minimal untuk mendukung perintah itu.

Saya tidak sepenuhnya up-to-date dengan API volume baru yang akan keluar, tetapi harapan saya adalah kami dapat menambahkan bagian volumes: untuk menulis yang akan menangani volume data dengan cara yang lebih baik (alih-alih membutuhkan wadah untuk mereka).

Ini belum tentu menjadikannya pilihan yang tepat, tetapi menurut saya kurva pembelajaran / kemudahan pemahaman harus dipertimbangkan.

Saya merasa (2) adalah yang paling mudah untuk dipahami. Saya tidak benar-benar memiliki cara untuk mengonfirmasi hal ini, tetapi naluri saya mengatakan kebanyakan orang yang tidak terlalu mengenal semua opsi docker-compose yang mengalami masalah yang sedang kami coba selesaikan di sini berkata, "Saya berharap ada cara agar penampung itu _tidak dimulai_ ketika saya menjalankan docker-compose up ," dan mereka melihat start: false dan bam, kami sudah selesai dan bahagia.

Mereka tidak mengatakan, "Seandainya ada cara saya dapat membuat file kedua dengan cerita yang menghubungkan canggung untuk menyelesaikan ini ..." (saya menyadari bahwa https://github.com/docker/compose/issues/ 1987 # Issuecomment-139632238 membantu dengan "cerita menghubungkan canggung," ya?).

(4) agak kabur, tetapi jalan khusus untuk skrip dan satu kali seperti ini cocok dengan tagihan "masuk akal" ini.

Hari ini saya mencari persis (2) tetapi berakhir dengan solusi yang paling tidak saya sukai, file YML kedua. Kasus penggunaan saya:

Saya memiliki beberapa wadah dan semuanya tertaut ke wadah mongo . Saya ingin menawarkan diri saya dan tim kemampuan untuk memuat perlengkapan ke dalam database mongo dan saya pikir cara termudah untuk melakukannya adalah dengan memuat kontainer mongo dengan nama yang berbeda fixtures itu itu sendiri menautkan ke mongo dan kemudian menjalankan mongorestore --host mongo --port 27017 --drop /dump . Karena kami tidak ingin memuat perlengkapan setiap saat, rasanya wajar memilikinya dengan start: false tetapi akhirnya memiliki file YML terpisah untuk kedua kontainer fixtures dan mongo .

Bekerja dengan baik tetapi start: false jauh lebih bersih IMO. Jika saya akan memiliki 10 atau lebih permutasi dari apa yang disebut wadah perlengkapan ini maka ya start: false akan menjadi ide yang buruk dan saya akan menggunakan (1) .

Hanya perlu membuat file penulisan di mana beberapa layanan tidak boleh dijalankan dengan perintah docker-compose up -d . Bagi saya opsi (2) akan menjadi solusi terbaik untuk masalah saya.

Saya telah menemukan ini juga. Tidak yakin mana yang menurut saya merupakan solusi terbaik, tetapi yang menjadi perhatian saya adalah saya membutuhkan kemampuan untuk membangun gambar yang digunakan sebagai bagian dari komposisi. Mereka untuk penampung sementara, tapi saya perlu gambarnya untuk siap digunakan sehingga saya dapat menjalankan penampung sesuai permintaan.

Hai! masalah yang sama di sini, senang ada masalah pengelompokan yang bagus, kerja bagus!

Dalam kasus saya, saya memiliki tumpukan python yang bekerja dengan beberapa wadah dengan layanan. Semuanya bekerja dengan baik, tetapi saya baru saja menemukan sebuah kasus dari tumpukan. Saya mengelola dependensi statis dengan bower, dan ingin menjalankan perintah bower di dalam container, itu hanya skrip yang kami jalankan sesekali.

Akan sangat bagus untuk menjalankan skrip ini dalam struktur penulisan yang kita miliki. Saya membayangkan sesuatu seperti:
docker-compose jalankan node bower install

Jadi saya suka opsi ke-2 dari ke-4. Hanya perlu layanan untuk tidak memulai, tidak diperlukan: P

Jika ada beberapa konsensus, saya dapat mencoba mengirim permintaan tarik untuk sesuatu seperti "restart"
mulai: selalu
mungkin ... tidak tahu.

Voting lain untuk opsi 2.

Saya lebih suka opsi 2 juga. Penampung Data Docker baru dapat ditentukan dalam file tulis-galangan tetapi mereka tidak perlu dijalankan untuk digunakan.

Opsi 2 untuk saya juga

Opsi 2 akan bagus.

1 untuk opsi 2

1 untuk opsi 2. Mempertahankan banyak file dan mengetik namanya hanya membuang-buang waktu. Satu bendera boolean akan mengatur semuanya. :bir:

1 untuk opt 4,
Jika saya harus memilih favorit kedua, pilihlah 2.

Benar bahwa opsi terbaik adalah 2,4 jika saya dapat memberi +1 pada keduanya maka itulah yang saya lakukan jika tidak, saya akan memilih mayoritas dan memilih 2.

Voting untuk 2 orang

baik 2 dan 4 bagus untuk dimiliki.
1 untuk 2

Saya rasa tidak perlu memperkenalkan konsep baru untuk tugas. Ini terbaca dengan sangat baik menurut saya dan dimungkinkan tanpa banyak modifikasi:

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

Menurut saya, "solusi" saat ini dengan file tulis terpisah sebenarnya bukan solusi. Seperti yang dikatakan @xaka , tidak ada yang mau mengetik semua ini:

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

Apa yang akan Anda dapatkan adalah skrip ./run-task yang menambahkan semua boilerplate sebelum myTask untuk Anda. Tapi sekarang Anda telah menambahkan entrypoint dan antarmuka lain ke aplikasi multi-container Anda. Pengembang melihat docker-compose.yml dan berpikir: _ "Wah, bagus sekali, aplikasi buat. Saya tahu cara menangani hal ini!" _ Dan sekarang Anda harus memberi tahu mereka: _ "Benar, Anda bisa mengelolanya dengan docker-compose seperti setiap aplikasi penulisan lainnya ... oh, tapi tunggu ... ada juga skrip tambahan yang perlu Anda ketahui ... "_

start: false / up: false / some-additional-flag-to-a-service: false mungkin adalah hal yang paling sederhana untuk diterapkan, tetapi kemungkinan besar juga yang paling jelas dan termudah untuk dipahami. Dan itu akan sangat meningkatkan kegunaan.

apa yang dikatakan @sherter . : arrow_up:

: +1: untuk itu. Dockerfile terpisah adalah masalah besar terutama ketika jaringan terlibat

Pendekatan start: true|false terlalu terbatas. Bagaimana jika beberapa layanan digunakan untuk pengujian, beberapa lainnya untuk admin dan sisanya untuk operasi normal?

Saya lebih suka menambahkan gagasan pengelompokan ke layanan.

    myservice:
       group: `admin`

Jika atribut group tidak ditentukan, diasumsikan default .
Dengan begitu kita dapat memulai layanan default dan admin menggunakan docker-compose up -g admin -d .

Lebih baik lagi, buat groups array.

Membuat layanan kelas grup tampaknya akan menjadi fitur yang hebat, tetapi juga tampaknya bersinggungan dengan masalah ini.

Pada docker-compose versi 2 , setiap penampung dideklarasikan di dalam services: top-level-item.
Mendeklarasikan layanan, dengan start: never untuk menjalankan skrip terdengar salah.
Jadi dengan mempertimbangkan format baru, bukankah kita harus mendeklarasikan item tingkat atas tambahan selain _services_, _volumes_ dan _networks_?

Lamaran ku:

• tambahkan item tingkat atas scripts: , transients: (atau pikirkan nama yang lebih baik) baru ke v2.
• di dalam transien, Anda dapat menentukan container seperti yang akan Anda lakukan dengan layanan apa pun
• satu-satunya perbedaan adalah bahwa mereka tidak akan _start secara default_, karena mereka ditujukan hanya untuk penggunaan sementara.

Contoh:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

Dan kemudian Anda dapat menjalankan:

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

Kekhawatiran:

• Kedengarannya OverPowered untuk membuat item tingkat atas lain hanya untuk tujuan pengelolaan awal ini, tetapi ini berasal dari fakta bahwa format baru menyatakan perilaku di tingkat atas.
• Saya mencoba membayangkan fleksibilitas ekstra (dan masalah) yang mungkin ditambahkan ini.

Terakhir, pada fitur _groups_, kedengarannya bagus tetapi jika Anda memiliki banyak pengelompokan, saya tidak melihat masalah dalam membuat file docker-compose untuk masing-masing file. Mungkin fitur yang Anda inginkan adalah warisan file docker-compose , itu akan luar biasa!

PD: @bfirsh mungkin jika Anda suka ide Anda dapat menambahkannya ke "Saran yang Mungkin"

Namun yang kedua ini adalah perubahan dari saran ke -

Pemberian suara untuk opsi 2: Paling jelas, paling mudah dibaca, dan tidak perlu mempelajari konsep baru
Hanya menginginkan layanan yang tidak dimulai secara default

Bagaimana dengan sesuatu seperti disabled: true

@ cpuguy83 Itu sepertinya menyiratkan bahwa seluruh layanan dinonaktifkan, bahkan untuk run . Saya akan merasa bingung.

@qcho hmm, sekarang saya telah membiasakan diri kembali dengan Docker sejak 1.6, saya dapat melihat apa yang Anda dan @gittycat bicarakan. Dalam hal ini, saya sangat menyukai pendekatan @gittycat . Saya membayangkan (langit biru) sebuah antarmuka seperti:

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

Sementara itu, di dalam cangkang…

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

Pendekatan seperti ini akan luar biasa dan meniadakan kebutuhan akan tiket ini, tetapi melampaui cakupannya.

@kojirike Saya rasa tidak. Beginilah cara sistem init merujuk ke layanan yang seharusnya tidak dimulai secara otomatis.

Ini juga sederhana dan "kebingungan" apa pun dapat diselesaikan dengan dokumentasi.
Saya juga merasa jauh lebih membingungkan daripada pengelompokan ini, yang sama sekali tidak terkait dengan konsep memulai layanan.

@ cpuguy83 Saya pikir semantik dari "services" adalah hal yang membingungkan di tempat pertama. Saya setuju bahwa pengelompokannya adalah scope creep. Dalam hal ini saya lebih suka pendekatan opsi 4 / @qcho , di mana mereka dengan jelas membedakan "layanan" dari "hal-hal yang bukan layanan".

Itulah intinya, mengapa saya harus meletakkan kontainer yang tidak akan pernah menjalankan layanan di bawah kategori "layanan ... dinonaktifkan". Kedengarannya seperti tambalan jelek yang dibuat seseorang dan tidak intuitif.

Mungkin "versi 2" dari format seharusnya memperhitungkan masalah ini. Misalnya spesifikasi lain bisa jadi

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

Ok sekarang kami memiliki layanan yang tepat, dengan definisi grup. Saya dapat memulai produksi atau kelompok layanan pengembangan. Atau jalankan saja skrip di some_script_container. karena tidak ditentukan dalam layanan apa pun, tidak ada yang akan dimulai

@qcho Bergantung pada definisi layanan, tetapi dalam hal apa pun - saya mempertanyakan sesuatu yang hanya boleh dijalankan sesekali, dan satu-satunya manusia yang dapat menentukan apakah harus dijalankan atau tidak.

Jadi katakanlah compose mengadopsi sesuatu seperti objek job .

1. pekerjaan hanya dijalankan sekali
2. pekerjaan dimulai setelah layanan
3. pekerjaan diharapkan keluar
4. ???

Sekarang compose juga perlu mempertahankan beberapa status lokal tentang tugas tersebut, yang saat ini tidak dilakukan sama sekali.

Itulah mengapa menambahkan auto-up: false atau autorun: false adalah cara termudah dan paling tidak menyeramkan (scopewise) untuk menangani ini.

@ cpuguy83 Saya rasa Anda memperluas apa yang saya katakan dengan sesuatu yang lebih kompleks. Saya tidak bermaksud menulis buruh pelabuhan jika mengetahui tentang pekerjaan atau alur kerja apa pun. Skrip eksternal dapat dibuat untuk itu. Apa yang saya maksudkan adalah bahwa pembuat galangan-galangan harus menentukan seluruh tumpukan untuk menjalankan aplikasi.

Saya bisa membayangkan diri saya membuat skrip dan mempertahankan keadaan yang Anda katakan. Bahkan memanggil skrip sebelum layanan dimulai, bukan hanya setelahnya. Apa yang tidak saya bayangkan adalah diri saya sendiri mengurai file komposer karena saya perlu memeriksa volume apa yang perlu saya impor, atau konfigurasi apa yang perlu saya ekstrak darinya pada wadah yang tidak dikenal untuk menjalankan beberapa skrip yang berlaku untuk itu. Jadi saya pikir buruh pelabuhan harus memberi saya wadah itu; menjalankan skrip dan menjaga status adalah masalah saya.

Saya tidak mengerti mengapa orang terus mengatakan itu

services:
  my-script-container:
    auto-up:false

Lebih sederhana dari:

scripts/containers/transients/you_name_it:
  my-script-container:

Itu tingkat kerumitan yang sama. Tapi kurang meretas secara semantik.

Untuk mendapatkan ide di satu utas, referensi # 2803

Kasus penggunaan: Anda memiliki proyek dengan banyak komponen dan pengguna apa yang harus dipilih dan memilih mana yang akan diinstal tetapi dia menulis file menginstal semuanya.

Proposal: Kami menambahkan opsi untuk dimasukkan ke dalam docker-cmpose.overrider.yml untuk mengecualikan gambar yang ditentukan di docker.compose

yaitu

beberapa gambar:
kecualikan: ya

Perilakunya akan mengabaikan entri itu di docker-compose.yml

Bisakah Anda memberi tahu saya apa yang tim pikirkan, saya akan tertarik untuk membuat perubahan.

Memberi suara untuk # 2 juga ... baru saja memenuhi kebutuhan ini hari ini.

Proposal @jimzucker juga akan bekerja, meskipun saya suka membayangkan melihat "start: false" di file .yaml utama untuk segera memberi petunjuk kepada Anda bahwa 'layanan' ini tidak akan berjalan kecuali Anda memanggilnya secara eksplisit. Jika tidak, Anda (atau dalam kasus saya, pengguna akhir / pengembang yang Anda serahkan pada file penulisan buruh pelabuhan) perlu ingat untuk mencari file timpaan.

+1 untuk 2. Saya mengalami situasi di mana saya perlu membuat gambar buruh pelabuhan sebagai bagian dari penulisan tetapi tidak berjalan sebagai layanan. Layanan lain (yang memiliki kaus kaki buruh pelabuhan dipasang di dalamnya) menjalankan kontainer dari gambar sesering mungkin.

+1 untuk 2. Dan +1 untuk kata-kata "naik otomatis" atau "jalankan otomatis".

Dan tidak bisakah kasus untuk grup layanan (seperti dijelaskan oleh @gittycat) ditangani melalui variabel lingkungan ala "auto-up: $ {ADMIN}"?

Saya juga melihat kasus penggunaan nyata untuk menandai layanan di docker-compose.yml agar tidak dimulai secara otomatis dengan docker-compose up tetapi hanya dimulai secara eksplisit.

Solusi 1) adalah salah satu cara yang mungkin sekarang tetapi menurut saya terlalu rumit karena seseorang harus menentukan satu atau lebih file yml daripada hanya memanggil docker-compose up dan harus membagi atau bahkan menggandakan file.

Karena saya benar-benar ingin melihat sesuatu seperti solusi 2) (seperti yang dilakukan banyak orang lain juga), saya menerapkan bukti konsep ini di # 3047 sehingga Anda dapat bermain-main sedikit dengannya untuk melihat apakah itu bisa menjadi layak larutan.

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2 dan 4

1 untuk opsi 2 dan 4

+1 untuk opsi 4. beberapa konfigurasi tidak boleh diizinkan untuk skrip (misalnya: restart: selalu)

dengan opsi 2, bisa jadi kasus aneh ini:

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

apa artinya itu?

@mathroc : Artinya: "Jangan mulai otomatis penampung ini saat penulisan dijalankan. Saat penampung ini berhenti (setelah dimulai secara eksplisit), mulai ulang apa pun kode keluarnya." Apa yang aneh tentang itu?

@niko oh benar, saya harus memikirkannya sedikit lebih lama sebelum memposting ...

mengubah "suara" saya menjadi +1 untuk opsi 2

1 untuk opsi 2, saya membutuhkan ini di banyak proyek.

ping @bfirsh @dnephin :
Bisakah Anda memberikan pembaruan tentang masalah ini? Karena sebagian besar komentar di sini mendukung opsi 2, apakah saat ini ada rencana untuk menerapkan sesuatu seperti itu (atau opsi 3/4)?
Saya dapat memoles permintaan tarik saya (# 3047) dan melengkapinya dengan tes dan dokumentasi jika Anda mempertimbangkan untuk menggabungkannya saat itu.

Terima kasih.

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2

Saya pikir opsi 1 dapat berfungsi, tetapi kami membutuhkan cara yang lebih baik untuk mengurangi verboseness:

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

Mungkinkah bisa menambahkan flag yang disederhanakan / augment? docker-compose --augment tests up dan secara otomatis menyelesaikan jika variasi dari docker-compose.yml - jika tidak, pengguna harus eksplisit.

Saya sangat menyukai ide kata kunci tingkat atas yang baru, mungkin suites dan commands ?

Konfigurasi berikut akan memungkinkan untuk:

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

Saya dapat melihat di kode bahwa sudah ada gagasan layanan "oneoff" (IMHO hanya digunakan ketika docker-compose run dipanggil.
Bisakah itu digunakan kembali?
Jika saya memberi label wadah dengan com.docker.compose.oneoff=True , apakah ia akan mencoba memulainya?

Jika tidak, saya memilih opsi 2.

Saya baru saja tersandung ini, jadi inilah dua kasus penggunaan saya:

1. Variabel lingkungan "global": Pendekatan yang disarankan di sini adalah menggunakan extends , yang tidak masalah bagi saya ... tapi sekarang saya perlu mendefinisikan image untuk hal yang saya kembangkan , dan bahkan tidak bisa menggunakan scratch (jadi berakhir dengan https://hub.docker.com/r/tianon/true/).
2. Layanan "penskalaan": secara default saya memiliki satu instance MongoDB, tetapi untuk beberapa pengujian, saya ingin menetapkan yang kedua tidak aktif, yang dapat saya tampilkan untuk pengujian tersebut. Di sini menggunakan extends dalam file yang berbeda tampak seperti ide yang layak (masih belajar tentang docker / docker-compose dan praktik terbaik yang terlibat).

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2
Sepertinya perubahan sederhana ...

+1 opsi 2,

dalam kasus penggunaan beberapa penampung yang berbagi sekumpulan env dan konfigurasi yang sama, masuk akal untuk membuat penampung dasar untuk memperluas dari tetapi tidak untuk benar-benar memulai penampung

auto-start:true|false

Memiliki solusi bagus sejak September lalu yang disebut rocker-compose , saya sarankan untuk menjalankan: _always_ | _once_ | _tidak pernah_. Saya juga suka state: _running_ | _ran_ | _created_ juga.

bukan penggemar menggunakan proyek terpisah hanya untuk fitur ini, saya akhirnya mencuri perintah kode asm True dari proyek tianon / true sampai ini diimplementasikan

Saya juga awalnya berpikir opsi 2 akan menjadi yang terbaik tetapi sekarang saya mulai berpikir itu akan terlalu membatasi dan segera setelah menambahkannya, kebutuhan untuk tugas run-sekali akan muncul. Sebenarnya saya sedang mengerjakan sebuah proyek sekarang di mana saya memiliki kebutuhan untuk kasus penggunaan berikut:

• dalam tumpukan Saya ingin dapat menentukan kontainer yang berjalan sekali pada penerapan awal dan setiap proses di masa depan hanya dipicu secara eksternal (misalnya jadwal / acara, melalui panggilan API, dll.) sehingga mereka dapat menginisialisasi / memperbarui status kontainer layanan utama dalam tumpukan yang sama (misalnya, data / skema DB, mengisi volume data, dll.)
• dalam tumpukan Saya ingin dapat menentukan kontainer yang hanya dipicu secara eksternal sehingga dapat digunakan untuk merangkum tugas utilitas / admin (mis. pemeriksaan status / data, dll.) dan proses yang dipicu sesuai jadwal (mis. cadangan) atau oleh kejadian eksternal (misalnya memicu proses pada perubahan ke keranjang S3)

Dalam kasus saya, perbedaan antara state: created (berjalan 0 kali) dan state: ran (berlari> = 1 kali) adalah penting karena beberapa tugas utilitas / admin mungkin merusak dan hanya digunakan dalam keadaan tertentu seperti layanan migrasi.

Mengingat bahwa saya sekarang lebih condong ke state: running | ran | created seperti dalam rocker-compose atau opsi 4 dengan level teratas _task_ atau _job_ object + kemampuan untuk mengekspresikan ketergantungan sehingga layanan dapat memicu tugas untuk dijalankan sebelum / sesudahnya sendiri .

Saya ingin menyebutkan bahwa ini penting untuk kasus penggunaan saya. Saya menggunakan docker-compose untuk membuat lingkungan pengujian dan menjalankan rangkaian pengujian. Masalah dengan memulai semua container sekaligus adalah saya tidak dapat dengan mudah mengizinkan service container (seperti database atau pekerja seledri) untuk menginisialisasi sebelum menjalankan rangkaian pengujian.

Akan lebih baik jika Anda dapat mencapai sesuatu seperti:

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

Anda dapat membayangkan sesuatu yang lebih rumit dari sleep 5 dapat ditulis untuk memverifikasi inisialisasi telah terjadi tetapi tidak diperlukan untuk cuplikan contoh.

Saya tidak membaca opsi tentang bendera cli. Jadi saya akan mengusulkan bendera --exclude ditambahkan ke daftar opsi. Bendera --exclude akan memberi tahu perintah up untuk tidak memulai wadah yang ditentukan. Bendera --exclude akan diurai sedemikian rupa sehingga beberapa kontainer dapat dikecualikan dari permulaan jika diperlukan.

: +1:

Pertimbangkan kasus penggunaan lain di mana opsi 2 akan menjadi solusi yang sesuai: melakukan iterasi pada subservice baru dalam aplikasi yang sudah ada. Sebagian besar pengembang di proyek ini belum membutuhkan layanan baru, dan Anda pasti tidak ingin masalah dengan itu menghalangi pekerjaan mereka, tetapi Anda mungkin juga ingin menghindari pemeliharaan cabang di luar pohon untuk waktu yang lama. waktu.

File "docker-compose-eksperimental.yml" terpisah _could_ berfungsi, tetapi itu berarti semua dokumentasi untuk mengerjakan komponen itu perlu ditulis dengan satu cara saat komponen masih eksperimental, dan kemudian direvisi setelah menjadi bagian dari set standar layanan.

+1 untuk opsi 2

1 untuk Opsi 2

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2

@acran Saya ingin melihat Anda mengirimkan permintaan tarik Anda untuk melihat apakah kami bisa mendapatkan daya tarik untuk bergerak maju, mungkin jika Anda rebase untuk menghilangkan konflik di # 3047 itu akan diterima, tidak yakin bagaimana cara mendapatkan perhatian untuk ini.

@jimzucker well # 3047 sudah merupakan permintaan tarik dan saya masih menunggu beberapa komentar darinya oleh devs: kecewa:

Lihat komentar saya di atas : membuat PR layak penggabungan masih memerlukan beberapa pemolesan, yaitu memperbarui dokumen terkait dan kasus uji. Tapi saya lebih suka tidak melakukan pekerjaan itu tanpa mengetahui bahwa pendekatan ini akan dianggap terintegrasi oleh upstream. Kalau tidak, usaha saya dalam hal ini tidak ada gunanya ...

Opsi +1 2

@acran , saya ingin membantu Anda memperbarui dokumen terkait dan kasus pengujian. Apakah itu ok?

Opsi +1 2

atau mungkin mendefinisikan jenis Job, seperti di Kubernetes?

1 untuk opsi 2

Kami memiliki docker-compose dengan beberapa layanan dan salah satunya (database) harus diluncurkan di lingkungan pengembangan tetapi tidak di lingkungan produksi. Oleh karena itu, kami harus memelihara dua file docker-compose. Opsi 2 persis seperti yang kami cari!

: +1: untuk opsi 2

Opsi +1 2

@acran Saya menghubungi beberapa penghubung di SF untuk mengetahui proses / saluran yang tepat untuk mendapatkan umpan balik sehingga ini dapat bergerak maju, pantau terus;)

👍 untuk opsi 2

1 untuk opsi 2

Opsi +1 2

Opsi +1 2

Juga saya memilih opsi 2

Ide lain: sekarang kita memiliki networks dan volumes , kita juga dapat menambahkan opsi images . Ini akan menjadi petunjuk untuk Menulis bahwa gambar-gambar ini harus ditarik atau dibuat agar aplikasi berfungsi, tetapi gambar tersebut tidak akan dijalankan ketika Anda melakukan docker-compose up .

Ini akan bekerja untuk dua kasus penggunaan, di luar kepala saya:

1) Masalah umum di sini, di mana Anda ingin menjalankan beberapa jenis perintah manajemen. docker-compose run dapat kembali ke gambar yang sedang berjalan jika layanan tidak ada.
2) Aplikasi seperti ini yang menjalankan gambar Docker tetapi tidak berjalan sepanjang waktu.

/ cc @dnephin @aanand @ shin-

Kecuali bahwa akan menyenangkan untuk dapat mengkonfigurasi semua opsi yang dibutuhkan oleh container jangka pendek (yaitu volume / mount point, jaringan, link, nama, dll) di file docker-compose sehingga Anda tidak harus terus menambahkannya setiap kali Anda perlu menjalankan penampung itu ...

Pada 13 September 2016 3:58:41 AM CDT, Ben Firshman [email protected] menulis:

Ide lain: sekarang kami memiliki level teratas networks dan volumes , kami bisa
tambahkan juga opsi images . Ini akan menjadi petunjuk untuk menulis ini
gambar harus ditarik atau dibuat agar aplikasi berfungsi, tetapi gambar tersebut
tidak akan dijalankan ketika Anda melakukan docker-compose up .

Ini akan bekerja untuk dua kasus penggunaan, di luar kepala saya:

1) Masalah umum di sini, di mana Anda menginginkan semacam manajemen
perintah untuk menjalankan. docker-compose run dapat kembali ke gambar yang sedang berjalan
jika layanan tidak ada.
2) Aplikasi sepertiini yang lari
Gambar Docker tetapi tidak berjalan sepanjang waktu.

/ cc @dnephin @aanand @ shin-

Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/docker/compose/issues/1896#issuecomment -246618909

Dikirim dari perangkat Android saya dengan K-9 Mail. Maafkan singkatnya saya.

Saya setuju dengan @mgriego dalam hal ini. Pikirkan wadah penghasil build - akan lebih baik jika perintah dan opsi sudah disiapkan dan hanya docker-compose up foo dan biarkan ia melakukan build dan exit.

Mencoba untuk mendapatkan lebih banyak pemahaman di sini: Apakah opsi 2) hanya kasus khusus dari yang lebih umum "kami ingin nilai initial_scale dalam docker-compose.yml "? (lihat # 1661, # 2496 et. al.)

@ankon tidak sama sekali.

tambahkan images [bagian]

@bfirsh ini mulai bergerak ke arah yang saya ambil dengan https://github.com/dnephin/dobi. Saya tidak lagi memiliki "bagian" (dan hanya menggunakan item tingkat atas untuk setiap sumber daya). Saya pikir akan sulit membuatnya berfungsi dengan model Compose.

1. networks dan volumes tidak pernah benar-benar dioperasikan secara langsung, mereka hanya dibuat sesuai kebutuhan oleh wadah. Memisahkan gambar menjadi bagiannya sendiri tidak akan mengubah perilaku yang kita miliki sekarang, itu hanya akan membuat konfigurasi Tulis lebih rumit. Jika Anda hanya ingin membuat gambar, jalankan docker-compose build .
2. Saya tidak berpikir itu benar-benar memperbaiki masalah yang diidentifikasi dalam masalah ini. Orang menginginkan wadah, bukan hanya gambar

Membaca ulang utas dan diskusi di # 2496 tentang mendeklarasikan batasan penskalaan dalam file penulisan, saya mulai memilih Opsi 4 (yaitu bagian tingkat atas baru) daripada Opsi 2.

Secara khusus, nama bagian seperti utilities akan sesuai: komponen yang biasanya tidak diperlukan, tetapi ketika Anda membutuhkannya, Anda ingin mengkonfigurasi sebelumnya komponen lain yang ditautkan daripada harus ajak orang untuk membuat sendiri mantra docker run .

Pendekatan itu kemudian akan mencakup tidak hanya perintah admin satu kali, tetapi juga layanan debugging dan introspeksi tambahan seperti pgweb dan Celery Flower (yang sangat berguna untuk dijalankan dalam pengembangan, tetapi Anda biasanya tidak ingin dalam produksi karena keamanan tambahan area permukaan ancaman yang mereka buat).

Mendefinisikan semantik dari "bukan layanan" baru ini juga menjadi jauh lebih mudah: mereka _exactly_ sama dengan services (termasuk semua perubahan mendatang pada format tersebut), dengan satu-satunya pengecualian bahwa perintah yang tidak memenuhi syarat seperti docker-compose build , docker-compose pull , dan docker-compose up abaikan semuanya - jika Anda ingin komponen apa pun yang terdaftar di "utilitas" daripada "layanan" diproses, Anda perlu menamainya secara spesifik (meskipun ada mungkin bisa berupa opsi --all , mirip dengan opsi saat ini untuk docker-compose rm ). Namun, CLI untuk berinteraksi dengan utilitas ini berdasarkan nama akan identik dengan yang digunakan untuk berinteraksi dengan layanan normal (tidak seperti status quo, di mana Anda perlu menentukan file konfigurasi utilitas tambahan), dan docker-compose akan menangani pencegahan konflik nama. antara definisi layanan dan utilitas.

Meskipun proposal penskalaan di # 2496 berpotensi (ab) digunakan untuk mendapatkan perilaku ini, ini masih terasa seperti solusi daripada fitur yang dirancang dengan benar.

Saya suka desain itu, @ncoghlan.

Daripada utilities bagaimana dengan menamainya .services ? Ini secara alami menyampaikan bahwa services dan .services menggunakan semantik yang sama persis, satu-satunya perbedaan adalah bahwa .services tidak dijalankan secara default. Ini mirip dengan nama file yang tidak ditampilkan secara default. Saya kira sisi negatifnya adalah perbedaan antara keduanya agak tidak kentara.

Saya suka ide dasar yang dibicarakan @ncoghlan di sana, tapi…

1. Jangan setuju bahwa _all_ perintah yang tidak memenuhi syarat harus mengabaikan utilitas ini secara default. Menurut pendapat saya, semua perintah harus berjalan normal kecuali yang akan menghasilkan wadah yang berjalan. (Jadi pada dasarnya, up dan start .)
2. Mengenai komentar @dsem , saya suka semantik 'utility' lebih baik daripada '.services'. Saya memahami alasan file tersembunyi unixy, tetapi hal-hal ini bukan hanya layanan tersembunyi, mereka adalah pembantu layanan.

@bfirsh @ncoghlan Saya setuju sepenuhnya dengan @dnephin :

Saya tidak berpikir itu benar-benar memperbaiki masalah yang diidentifikasi dalam masalah ini. Orang menginginkan wadah, bukan hanya gambar

Apa yang saya - dan menurut saya sebagian besar orang di sini - butuhkan untuk alur kerja yang saya inginkan adalah layanan sederhana; mereka didefinisikan seperti layanan normal lainnya, mereka dimulai / dihentikan seperti layanan normal dll.
Perbedaan _only_ adalah bahwa mereka tidak secara otomatis dimulai dengan docker-compose up secara default tetapi hanya ketika ditentukan secara eksplisit (atau ditarik sebagai dependensi).

Oleh karena itu, saya tidak melihat adanya kebutuhan untuk bagian tingkat atas baru atau konsep yang benar-benar baru untuk wadah satu kali ini tetapi hanya opsional per parameter konfigurasi layanan.
Saya menerapkan ini dalam permintaan tarik saya # 3047 sebagai bukti konsep. Ini adalah perubahan yang cukup kecil tetapi akan sepenuhnya memenuhi kasus penggunaan saya. Jadi jika ada hal lain yang bisa saya lakukan, untuk menggabungkan ini, beri tahu saya (=

Bagi siapa saja yang ingin mengujinya, berikut perintah untuk membuat dan menjalankan docker-compose dalam sebuah container:

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran , saya ingin membantu Anda memperbarui dokumen terkait dan kasus pengujian. Apakah itu ok?

@ dattran-vn01 tentu saja, saya akan senang: smiley:

@acran dalam contoh Anda, satu-satunya perintah yang memiliki perilaku berbeda dari Tulis saat ini adalah yang pertama, dan perilaku tersebut dapat diselesaikan menggunakan up baz .
Anda juga dapat mencapai hal yang sama dengan menggunakan beberapa file Tulis.

Memiliki beberapa perintah yang beroperasi pada daftar layanan default yang berbeda tampaknya sangat membingungkan, dan menjadi salah satu alasan saya tidak menyukai fitur ini.

@acran dalam contoh Anda, satu-satunya perintah yang memiliki perilaku berbeda dari Tulis saat ini adalah yang pertama, dan perilaku tersebut dapat diselesaikan menggunakan baz.
Anda juga dapat mencapai hal yang sama dengan menggunakan beberapa file Tulis.

@dnephin ya, tepatnya, saya tahu, dan dalam contoh ini akan menjadi cara termudah.
Tetapi bayangkan ini dengan 10 layanan dan hanya satu layanan sekali (seperti "init" atau "backup" / "dump"): dalam hal ini Anda harus mencantumkan semua layanan pada baris perintah kecuali yang satu itu- off layanan seperti docker-compose up service1 service2 ... service10 (lihat di bawah). Terutama Anda harus mengingat semua layanan dan secara manual melacak setiap perubahan dalam docker-compose.yml .

Saya juga tahu tentang kemungkinan menggunakan beberapa file YAML, lihat komentar pertama saya di atas , dan ini serta secara eksplisit memberikan semua layanan pada baris perintah memang mencakup sebagian besar kasus penggunaan yang disebutkan di sini; tetapi ini lebih terasa seperti solusi untuk digunakan.

Berikut contoh lain docker-compose.yml untuk memvisualisasikan masalah:

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

Atribut docker-compose up _with_ sederhana auto_up dimulai di sini semua layanan kecuali layanan init . Untuk mencapai hal yang sama tanpanya akan membutuhkan pengetikan perintah yang lebih lama dengan 10 layanan atau memisahkan file YAML dan harus menentukan beberapa file.

Jadi fitur yang diminta di sini lebih tentang kenyamanan dan lebih sedikit mengetik di cli dan bukan tentang fitur yang sama sekali baru.

Mengenai opsi "gunakan beberapa file konfigurasi" (yang memang merupakan opsi terbaik yang tersedia saat ini), masalah kegunaannya adalah dalam praktiknya terlihat seperti ini:

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

Perbedaan tersebut kemudian menginfeksi _all_ dokumentasi dan otomatisasi proyek Anda: Anda harus memastikan _two_ file compose tersedia bagi siapa saja yang ingin menjalankan perintah utilitas, Anda harus memastikan bahwa pemanggilan penuh diberikan untuk perintah di file utilitas, dan jika ada perintah atau layanan pernah diturunkan dari "selalu berjalan" menjadi "hanya dijalankan saat diminta secara eksplisit", Anda harus mencari pemanggilan yang tidak menyediakan nama file konfigurasi dan menambahkannya.

Itu semua _doable_, hanya mengganggu dibandingkan dengan mengatakan di file compose "Jalankan ini hanya ketika saya secara eksplisit meminta Anda, jangan pernah menjalankannya secara default".

Seseorang pernah berkata kepada saya: _ "Jika beberapa orang pintar tidak dapat memutuskan pendekatan mana yang terbaik, biasanya keduanya tidak terlalu buruk. Yang terburuk adalah tidak melakukan apa-apa." _

Kartu ini sepertinya contoh utama dari ini :)

Mengingat bahwa buruh pelabuhan sekarang mendukung konsep layanan secara asli untuk perintah yang berjalan lama, saya pikir pendekatan terbaik adalah menambahkan bagian baru yang disebut perintah yang memungkinkan fungsionalitas yang sama daripada layanan kecuali untuk kebijakan mulai ulang, yang harus dilarang.

Dalam pengaturan saya, saya memiliki layanan di docker-compose yang diperlukan untuk menjalankan infrastruktur saya (nginx, database, webserver, antrian pesan ...). Saya juga telah menetapkan layanan tambahan yang saya hanya perlukan untuk alasan debugging (misalnya database web gui).

Saya ingin layanan "debugging" TIDAK dimulai secara otomatis, tetapi jika saya ingin menambahkannya, saya dapat melakukannya dengan docker-compose up -d database-gui dan itu baru saja ditambahkan.

Juga: Kadang-kadang saya berubah pikiran dan ingin salah satu layanan ini selalu dimulai ... => Dengan opsi 2) Saya bisa mengubah satu bendera itu

=> Pilih opsi dua, karena sederhana dan tampaknya memenuhi persyaratan semua orang di sini. Setiap solusi lain terasa seperti rekayasa berlebihan bagi saya ... Menambahkan kompleksitas ke konfigurasi berdasarkan kasus penggunaan yang jarang atau hanya khayalan, bukan pada kebutuhan praktis.

Hanya di sini untuk menambahkan +1 saya. Saya menjalankan aplikasi Django dan ketika menjalankannya di buruh pelabuhan alangkah baiknya memiliki wadah yang akan menjalankan shell atau tes atau dalam hal ini perintah migrasi. Tetapi saya tidak ingin menjalankan semua ini setiap kali saya memulai aplikasi. Meskipun menggunakan beberapa file konfigurasi akan berfungsi, itu akan membutuhkan pengetikan, skrip, atau baris perintah sepanjang mil aliasing. Jika saya ingin melakukan itu, saya tidak akan menggunakan compose sama sekali, saya hanya akan shell script container saya (atau script python mereka ... mungkin menambahkan file YAML pemersatu untuk menyimpan konfigurasi container ... tunggu ...) Saya tidak tidak ingin melakukan hal seperti docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate hanya untuk menjalankan migrasi database di container saya. Alternatifnya adalah menggunakan /bin/true sebagai perintah dan melakukan sesuatu seperti docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' yang juga tidak terlalu elegan. Jadi menyimpan satu kali perintah di suatu tempat dalam konfigurasi akan sangat berguna bagi saya. Salah satu opsi 2, 3 dan 4 akan bekerja untuk saya.

Saya ingin menyarankan Anda untuk melihat dobi , yang merupakan alat yang telah saya kerjakan sebagian berdasarkan masukan dari utas ini.

compose dirancang untuk memulai layanan yang berjalan lama yang membentuk "lingkungan".
dobi difokuskan pada tugas pembangunan proyek berurutan.

Hal-hal yang Anda cari (menjalankan shell, menjalankan pengujian unit, menjalankan migrasi) semuanya adalah tugas proyek, sehingga lebih cocok dalam model dobi.

dobi dan compose bekerja dengan cukup baik, Anda dapat meluncurkan compose dari dobi menggunakan resource compose .

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

yang dapat Anda jalankan menggunakan:

dobi dev-environment

Ada contoh integrasi penulisan dan menjalankan migrasi db di sini: https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

Ada contoh dari banyak alur kerja (termasuk menjalankan pengujian, memulai shell interaktif, merilis, dan membuat gambar minimal) di sini: http://dnephin.github.io/dobi/examples.html

1 untuk 2). Dalam sudut pandang kami Tidak perlu memikirkan dan mendiskusikan kasus penggunaan yang tidak biasa seperti perintah satu kali, tetapi kami hanya ingin memiliki layanan nyata yang dibuat dan siap digunakan, tetapi dapat dimulai sesuai permintaan saat diperlukan (dan default jangan gunakan sumber daya).

"kasus penggunaan yang tidak umum"? apakah Anda menjalankan migrasi database? apakah Anda menjalankan tes unit? apakah kamu menjalankan lint? webpack?

Ya saya jalankan tapi itu bisa dicapai dan dikontrol di dalam container, menurut saya. Tapi saya tidak ingin mengurangi pandangan atau tuntutan Anda, jangan biarkan diskusi ini berkobar. Persyaratan kami tentang pembuatan galangan kapal tidak selalu bertentangan.

Saya baru saja menemukan utas ini mencoba menemukan cara untuk membuat wadah pembuat galangan untuk skrip yang menghapus database di wadah mysql saya dan memuat ulang skema dari dump yang diunduh. Ini adalah proses yang sangat panjang dan merusak, jadi saya tidak ingin menjalankannya setiap kali saya membuka layanan, tetapi juga perlu dijalankan di dalam kumpulan wadah yang tersusun menggunakan file galangannya sendiri.

Sebut mereka tugas, perintah, apa pun, tapi saya agak SOL tanpa itu.

Saya tersandung pada ini mencari sesuatu yang lain, hanya ingin chip dalam kasus penggunaan ... Kami menemukan bahwa pengembang kami adalah yang paling mampu menentukan data apa yang harus dicadangkan dari layanan mereka. Karena file docker-compose.yml ada di tangan mereka dan volume bernama digunakan, kami memutuskan untuk menggunakannya untuk menentukan strategi cadangan ... Berikut adalah contoh ringkasan dari docker-compose.yml lama kami yang kami gunakan.

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

Untuk dapat mencadangkan data volume, kami memutuskan untuk menggunakan wadah busybox untuk menyimpan data yang diperlukan, tetapi harus fleksibel dan hanya melakukan volume yang ingin dicadangkan oleh pengembang. Terakhir, kami harus dapat mencadangkan setiap volume secara terpisah. Untuk mencapai ini, kami menambahkan 3 layanan ke semua docker-compose.yml kami

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

Layanan pencadangan dan pemulihan hanya perlu dikonfigurasi menggunakan volume, perintah akan melakukan sisanya. Kami berencana menambahkan sedikit konfigurasi untuk dapat memilih volume mana yang akan dicadangkan atau dipulihkan tetapi untuk saat ini, kami melakukan semuanya ... Karena kami tidak ingin 2 layanan tersebut dimulai pada setiap pembuatan galangan kapal up perintah, kami perlu menentukan semua layanan yang kami inginkan, yang bisa membosankan ... Jadi kami menambahkan layanan dummy yang disebut boot, semua yang dilakukannya adalah bergantung pada semua layanan yang perlu dijalankan dan kami hanya memanggil yang ini ketika kami buruh pelabuhan-menulis.

Ini di sini penuh dengan peretasan kecil, tetapi memungkinkan kita untuk dengan mudah menjalankan docker-compose up backup agar cadangan kita disimpan di host / backups / latest dan dari sana kita menjalankan logika versionning / pruning.

Saya harap ini membantu seseorang yang mencoba mencapai sesuatu yang serupa ... Tetapi pada akhirnya, dapat memberi tahu docker-compose untuk tidak mem-boot 2 layanan tersebut, kami tidak memerlukan layanan yang ketiga dan mempersulit pembuatan docker kami perintah.

Dalam pengembangan, saat ini kami memiliki 4 file pembuatan-galangan:

• docker-compose.yml : Mendefinisikan layanan inti yang diperlukan untuk mengoperasikan aplikasi kita secara penuh, misalnya redis, MySQL, php-fpm, prosesor antrian Laravel, nginx, Solr
• docker-compose-utils.yml : Mendefinisikan layanan utilitas yang diperlukan untuk menjalankan tugas-tugas dev, misalnya gulp, npm, artisan (Laravel), komposer, redis-cli, biasanya dijalankan dengan layanan di atas
• 2 lebih banyak file docker-compose untuk menentukan lingkungan dan volume untuk layanan di atas

Setup ini bekerja dengan baik karena, di luar Docker, kami memiliki dependensi minimum untuk lingkungan dev kami. Kekurangannya adalah baris perintah yang diperlukan untuk menentukan semua file .yml yang diperlukan untuk menjalankan utilitas sederhana.

Kami mengembangkan di macOS, Windows, dan Linux. Selain itu, banyak tugas dev kami memerlukan beberapa jenis parameterisasi (misalnya membuat migrasi DB, menjalankan perintah composer / artisan / npm dengan argumennya sendiri), jadi saya membuat schmich/runx sebagai zero-install cross- platform task runner untuk menggabungkan tugas pengembangan umum kita.

Misalnya, ini memungkinkan kita mengatakan runx migrate: make create_some_table untuk menjalankan docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table secara efektif, atau runx npm usang untuk melihat dependensi JS yang sudah ketinggalan zaman.

Saya belum pernah menggunakan dobi disebutkan di atas, tetapi runx terasa serupa dalam semangatnya, meskipun kurang disesuaikan dengan lingkungan Docker. Pada akhirnya, saya ingin menghindari ketergantungan di mana-mana kecuali jika benar-benar dibutuhkan: untuk layanan itu sendiri, dan untuk skrip utilitas yang diperlukan dalam pengembangan.

Ada berita? Menurut saya fitur ini akan sangat menyenangkan untuk dimiliki! Saya memilih solusi dari konfigurasi tingkat atas seperti default mana kita dapat menentukan layanan apa yang harus dijalankan.
Layanan dummy boot bagus, namun saya lebih suka meninggalkan proses di latar depan, oleh karena itu ketika saya selesai dengan pekerjaan ini saya cukup menutup terminal untuk menurunkan semuanya. Ini juga bagus untuk memiliki keluaran yang terpasang secara default dan ini tidak terjadi dengan layanan dummy.

Karena noboby mengomentari kasus penggunaan menggunakan file .env, ini milik saya:

Saya memiliki 4 file penulisan: docker-compose.yml, docker-compose.local.yml, docker-compose.prod.yml dan docker-compose.ci.yml. Untuk setiap lingkungan saya memiliki .env yang berbeda:

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

Dan seterusnya...

Pengguna dan / atau skrip tidak perlu khawatir tentang file penulisan mana yang akan digunakan karena lingkungan sudah dikonfigurasi secara individual.

Tapi saya memiliki contoh pemeliharaan untuk dijalankan pada akhirnya, itu tidak dapat dikonfigurasi di dalam utama docker-compose.yml dan satu solusi adalah membuat docker-compose.worker.yml dan menjalankan baris perintah dengan 3 opsi "-f" yang berubah dengan lingkungan masing-masing. Itu terlalu rentan kesalahan untuk menjadi opsi yang dapat digunakan.

Solusi yang saya temukan adalah dengan membuat direktori "pekerja", letakkan file yml di sana, tautkan file .env atas ke direktori ini dan buat file .yml docker-compose kosong. [Ci | local | prod] (jika tidak, saya akan melakukannya untuk mengubah nilai variabel COMPOSE_FILE).

Ini berfungsi dengan baik, tetapi masih jauh dari optimal. Solusi lain dari OP akan menyelesaikan ini tanpa kekacauan.

Saya pikir pembahasan di sini, banyaknya contoh kasus penggunaan serta fakta bahwa sering ada masalah duplikat untuk ini dibuka membuat cukup jelas bahwa _adalah_ permintaan nyata oleh banyak pengguna untuk kemungkinan untuk "Menentukan layanan yang tidak dimulai secara default ".

Oleh karena itu saya benar-benar ingin memindahkan diskusi di sini dari _if_ ini harus diimplementasikan lebih banyak ke _ bagaimana_ ini harus diimplementasikan. Bisakah kita semua setuju tentang ini ?

Mengenai _how_ ini bisa dicapai @bfirsh mencantumkan beberapa opsi di komentar pembuka:

1) Sarankan pengguna untuk menggunakan file Tulis terpisah

Ini adalah satu-satunya solusi yang tersedia saat ini untuk kasus penggunaan ini. Tetapi seperti yang dikatakan di atas, dalam hal ini lebih merupakan solusi karena memerlukan pengetikan baris perintah yang panjang secara manual dan mengingat file Tulis mana yang akan disertakan untuk perintah mana yang akan dijalankan.
Tentu saja, dalam penyiapan CI atau penerapan otomatis ke produksi, hal ini tidak menjadi masalah, karena baris perintah hanya harus ditentukan sekali dan tidak pernah diketik secara manual. Jadi, ini semata-mata tentang kenyamanan di lingkungan non-otomatis, yaitu pengembangan, yang menurut manual docker-compose salah satu kasus penggunaan utama Compose itu sendiri:

Bersama-sama, fitur-fitur ini memberikan cara yang nyaman bagi pengembang untuk memulai sebuah proyek. Tulis dapat mengurangi "panduan memulai developer" multi-halaman menjadi satu file Tulis yang dapat dibaca mesin dan beberapa perintah.

Harus mengetik sesuatu seperti docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init hanya untuk menginisialisasi pengaturan lokal tidak terdengar _convenient_ bagi saya tetapi lebih seperti sesuatu yang dapat ditemukan di _a multi-halaman “panduan memulai pengembang” _.

Dan untuk mempertimbangkan opsi 1b) di sini:

Sarankan pengguna untuk menggunakan skrip / alat pembungkus untuk menggunakan file Tulis terpisah

Jika saya harus menarik alat dan dependensi tambahan hanya untuk ini, mengapa menggunakan docker-compose ? Karena semua yang dilakukan docker-compose dapat - secara teori - juga dilakukan hanya dengan skrip shell kustom dan klien asli docker secara langsung.
Saya melihat keuntungan utama dari docker-compose di antarmuka pengguna standarnya (Saya mengkloning proyek, melihat docker-compose.yml di sana dan tahu saya hanya perlu menjalankan docker-compose up untuk memulai) . Selalu harus mengetahui file compose mana yang akan digunakan untuk apa yang melemahkan keunggulan ini secara drastis.

2) Tambahkan opsi ke layanan agar tidak dimulai secara default
3) Tambahkan opsi konfigurasi tingkat atas untuk menentukan layanan default

Kedua opsi ini pada dasarnya melakukan hal yang sama: tentukan layanan mana yang harus (tidak) dimulai secara default dalam satu file tulis , opsi 2) dengan memasukkan layanan individual ke daftar hitam, opsi 3) dengan memasukkan kumpulan layanan ke daftar putih secara global.
Mempertimbangkan bahwa sebagian besar waktu terdapat lebih banyak layanan default daripada "layanan satu kali" dalam satu file tulis, mungkin lebih mudah untuk memasukkan satu layanan ke daftar hitam daripada harus memasukkan semua layanan lainnya ke daftar putih dan harus memperbarui daftar putih setiap kali layanan default mendapat ditambahkan atau dihapus. Juga dengan opsi 2) menggabungkan beberapa file tulis mungkin lebih mudah.

4) Tambahkan konsep sesuatu seperti layanan, tetapi hanya untuk perintah satu kali ("skrip", "tugas", dll ...)

Saya pikir opsi 4) hanyalah spesialisasi dari opsi 2) atau 3) karena di sebagian besar contoh di atas, wadah satu kali yang diinginkan pada dasarnya didefinisikan sama seperti layanan lain dan tidak melakukan apa pun yang lebih atau kurang seperti layanan normal - kecuali bahwa mereka tidak dimulai secara default. (Atau apakah saya melewatkan beberapa perbedaan signifikan dengan "layanan").

Jadi menurut pendapat saya, opsi 2) adalah pilihan terbaik di sini, karena memerlukan paling sedikit perubahan tetapi pada saat yang sama cukup fleksibel untuk memenuhi sebagian besar (atau semua?) Kasus penggunaan yang disebutkan di sini dan sangat nyaman digunakan pada saat yang bersamaan.
Namun demikian, saya akan sama senangnya jika melihat opsi seperti 3) atau 4) digabungkan ke hulu. Jadi setelah lebih dari setahun diskusi di sini, apakah ada garis waktu kapan atau apakah ini akan terjadi ??

Saya setuju bahwa opsi 2 mungkin yang paling tidak invasif. Satu-satunya fitur yang saya lihat bahwa opsi 4 mungkin menyediakan adalah kemampuan untuk menjalankan perintah pada kontainer yang ada (menggunakan mekanisme exec buruh pelabuhan). Misalnya, jika yang saya inginkan hanyalah menjalankan migrasi database atau pengujian unit, mungkin tidak ada alasan untuk membuat seluruh penampung terpisah untuk itu jika saya sudah memiliki penampung yang menjalankan aplikasi saya. Konon, wadahnya ringan dan saya akan sangat senang dengan opsi 2.

@MadWombat Saya memiliki perasaan yang sama tentang opsi 4, itulah mengapa saya mengusulkan fitur lain untuk kasus penggunaan ini: # 4096. Ada tumpang tindih dengan fitur yang dijelaskan di sini, tetapi saya yakin ini bisa berguna sendiri atau sebagai tambahan untuk fitur ini

@ mathroc Saya menyebutkan opsi 4 menggunakan buruh pelabuhan exec, karena @acran bertanya apakah ada perbedaan yang signifikan antara opsi 2 dan 4. Namun, saya tidak dapat menemukan kasus penggunaan kehidupan nyata di mana Anda secara khusus ingin menjalankan perintah pada wadah yang ada daripada membawa wadah lain yang serupa untuk tujuan tersebut. Mungkin ada beberapa skenario dengan koneksi persisten terbatas ke beberapa layanan atau beberapa sumber daya terbatas lainnya yang sudah digunakan oleh kontainer yang ada, tapi saya tidak dapat memikirkannya.

Satu-satunya fitur yang saya lihat bahwa opsi 4 mungkin menyediakan adalah kemampuan untuk menjalankan perintah pada kontainer yang ada (menggunakan mekanisme exec buruh pelabuhan).

Itu memang kasus penggunaan baru yang akan membenarkan (dan mengharuskan) memperkenalkan konsep tingkat atas baru yang berbeda dari layanan. Tetapi selama perintah tidak perlu dijalankan melalui docker exec dalam wadah layanan yang sudah ada, konsep layanan yang ada sudah cukup.

Saya tidak bisa, bagaimanapun, datang dengan kasus penggunaan kehidupan nyata di mana Anda secara khusus ingin menjalankan perintah pada penampung yang ada daripada membawa penampung serupa lainnya untuk tujuan tersebut.

Kasus terdekat yang dapat saya pikirkan adalah sesuatu seperti mengubah file konfigurasi di dalam wadah dan memicu pemuatan ulang oleh aplikasi; menggunakan contoh @mathroc dari # 4096:

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

Meskipun terkait dengan masalah ini, # 4096 memiliki kasus penggunaannya sendiri dan mungkin opsi 4) sebaiknya dipindahkan ke sana?

Sudah lebih dari setahun diskusi dan kami tampaknya tidak lebih maju membuat keputusan. @bfirsh sebaiknya memilih satu gaya dan mengikutinya: smile:

+1

+1, itu akan menjadi fitur yang sangat berguna untuk dimiliki.

Dan satu lagi +1 untuk opsi 2, dengan sesuatu seperti auto-start: false atau enabled: false .

Kasus penggunaan saya adalah memperluas layanan. Tidak mungkin memperluas layanan yang memiliki set depends_on , jadi yang ingin saya lakukan adalah menentukan template layanan, dan kemudian memperluas beberapa layanan darinya. Jelas, template harus dibuat, tetapi tidak berjalan secara otomatis.

Saya membuat solusi saya sendiri, bebas digunakan.
Ini masih dalam Beta :)

https://github.com/jonathanborges/picles-docker

Banyak pilihan bagus di sini. Kebutuhan akan fitur itu nyata.

Opsi 2 jelas lebih populer, kejadian:

1 -> 4
2 -> 52
3 -> 3
4 -> 10

👍 lainnya untuk opsi 2

Kita dapat menangani ini dengan cukup mudah dalam layanan "alat" dengan titik masuk awal atau perintah yang kembali. Kemudian kami menjalankan layanan ini dengan perintah alternatif untuk melakukan apa yang kami inginkan (misalnya menguji atau menyemai data). Misalnya

docker-compuse up -d
docker-compose run tools tests

Ya, layanan alat akan ditampilkan sebagai "dihentikan" di docker-compose ps . Jika ini tidak dapat diterima, maka saya opsi multi-file dari https://github.com/docker/compose/pull/2051 berfungsi. misalnya

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

Meskipun sepertinya banyak pembantu orkestrasi sedang ditulis untuk kebutuhan ini dan saya bersalah karena mengerjakannya juga :).

Secara pribadi saya percaya ada cukup solusi (seperti dua di atas; menjadi kreatif dengan entrypoints / containers Anda dan / atau menggunakan pendekatan multifile dengan alias shell / helper), dan penulisan dapat dibuat sederhana.

@briceburg lihat pembahasan di atas : masalah di sini bukanlah tentang fungsionalitas yang hilang yang tidak dapat dilakukan dengan cara lain. Ada _are_ solusi untuk hampir semua hal yang ingin dicapai orang di sini. Tapi itu solusi dan peretasan kotor, bukan kasus penggunaan normal dari buruh pelabuhan.

Ini tentang kenyamanan, tentang tidak harus mengetik docker-compose -f docker-compose.yml -f docker-compose-tools.yml up dengan tangan di cli, ini tentang tidak harus mengingat apakah itu docker-compose run tools tests atau docker-compose run utils tests atau bahkan harus bergantung pada sebuah _multi-halaman “panduan memulai pengembang” _ tetapi memiliki antarmuka yang terpadu dan sederhana untuk pengembang.

Sekali lagi, CCing @bfirsh, @dnephin: bisa tolong berikan _any_ umpan balik untuk masalah ini? Adakah harapan kita bisa melihat sesuatu seperti ini di peta jalan yang akan datang untuk docker-compose ??

@briceburg untuk lingkungan yang sederhana mungkin solusinya dapat diterima, tetapi terkadang tidak. Lihat penyiapan saya:

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

Saya memiliki 8 file penulisan (yang saya gunakan dalam beberapa kombinasi) selain yang ada di direktori worker , tempat saya mengonfigurasi wadah 'jangan mulai secara default'. Direktori worker (dengan file .env yang ditautkan ke induk dan beberapa file tulis kosong untuk kepatuhan dengan variabel .env COMPOSE_FILE induk) adalah solusi saya, tetapi hidup saya akan jauh lebih mudah ketika kami memiliki solusi untuk masalah ini.

@vipseixas sulit untuk mengukur kewarasan solusi ini dari daftar file - meskipun ya, saya setuju memiliki kemampuan untuk tidak memulai layanan secara otomatis tidak masalah. Saya hanya menyarankan agar Anda menggunakan titik entri / perintah default yang tidak melakukan apa pun untuk layanan yang Anda sukai _not_ daripada mulai otomatis. Misalnya, container keluar secara default ... dan untuk menjalankan layanan tersebut dengan perintah alternatif melalui proses penulisan galangan berikutnya.

Dalam kebanyakan kasus, Anda ingin memastikan health-check lolos pada layanan / container yang bergantung sebelum menjalankan pengujian - misalnya jenkins UP dan berjalan (menerima koneksi pada: 8080 atau apa pun) sebelum pengujian ini dijalankan. Dulu saya menggunakan buruh pelabuhan untuk ini.

Jika saya mengusulkan poin perak, itu akan memungkinkan pengaturan profil tulis melalui variabel lingkungan (misalnya DOCKER_COMPOSE_PROFILE = "tes"), dan untuk memungkinkan layanan bergantung pada profil - di mana semua layanan default ke "default "profil atau apa pun. Saya juga akan memastikan layanan yang bergantung pada layanan lain juga _dependent_ pada layanan itu 'HEALTHCHECK. Jadi seperti itu

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

1 untuk opsi 2.

Banyak di sini telah mengusulkan fitur-fitur baru yang menarik, tetapi apa inti masalahnya di sini? Saya memilih untuk membuatnya sesederhana mungkin.

Saat ini, kami berasumsi bahwa semua layanan di docker-compose.yml kami akan dibawa ke docker-compose up . Kami semua bekerja dengan skrip bootstrap kustom kami sendiri, makefile, build tools, dll., Dan untungnya baik docker-compose dan docker mengekspos API ekstensif untuk pengelolaan container individu setelah kitchen sink 'naik'.

Satu-satunya kebutuhan saya, kebutuhan inti yang membawa saya ke diskusi ini, adalah untuk menentukan bahwa salah satu layanan yang telah saya definisikan bukanlah sesuatu yang saya ingin 'naik' secara default, untuk alasan apa pun.

Apa fitur paling sederhana yang mungkin "menyelesaikannya" bagi kita semua? Ini adalah pembaruan kecil untuk spesifikasi docker- compose.yml ( autostart: false

Saya memilih: "LAKUKAN SESUATU UNTUK KITA, TERIMA KASIH." Kami memilih, kami sekarang membutuhkan setidaknya satu jawaban. 4 TUHAN!

Apa fitur paling sederhana yang mungkin "menyelesaikannya" bagi kita semua? Ini adalah pembaruan kecil untuk spesifikasi docker- compose.yml (

Itu jauh lebih baik daripada alternatif lainnya :)

Ini sangat mudah.
scale: 0
https://github.com/docker/compose/issues/1661

@ drew-r apa?

@ jonathanborges1542 Ini docker-compose scale servname=2 . Tidak ada yang setara dalam file docker-compose.yml .

@drew-r scale: 0 saat ini memberitahu daemon buruh pelabuhan untuk mengirim SIGTERM / SIGKILL ke semua kontainer untuk layanan tersebut. Ini akan menghentikan pekerjaan pemeliharaan apa pun meskipun belum menyelesaikan tugasnya. Itu adalah perilaku yang diharapkan. Mengubah ini akan menjadi kasus buruk karena membebani secara berlebihan apa yang merupakan perilaku yang jelas saat ini.

@gittycat Saya mengerti, tapi yang kami inginkan di sini adalah mengetik "docker-compose up" dan semuanya akan siap. Maka dalam kasus itu itu tidak akan berhasil.

Saya telah mengikuti topik ini selama lebih dari setahun sekarang (kebanyakan posting ada di sisi buruh pelabuhan).
Saya percaya bahwa "pekerjaan" tingkat atas baru yang hidup bersama "layanan", "volume", dan "jaringan" adalah pilihan terbaik. Itu opsi 4 di daftar OP di atas.
Ini juga merupakan proposal di repo Docker.
https://github.com/docker/docker/issues/23880

@tokopedia

sulit untuk mengukur kewarasan solusi ini dari daftar file

Tujuannya hanya untuk menunjukkan bahwa saya memiliki banyak kombinasi file dan menggunakan beberapa opsi "-f" terlalu rawan kesalahan untuk dilakukan secara manual.

Saya hanya menyarankan agar Anda menggunakan titik entri / perintah default yang tidak melakukan apa pun untuk layanan yang Anda pilih untuk tidak memulai secara otomatis.

Terkadang tidak ada jalan keluar dari malapetaka. Tetapi saya lebih memilih solusi saya: Saya menggunakan direktori lain yang tidak akan pernah "dibuat-buat" sehingga tidak akan ada kontainer yang berhenti dan tidak berguna yang mencemari lingkungan saya. Itulah mengapa saya memiliki direktori pekerja dengan ".env" yang ditautkan ke induk ".env".

Jika saya mengusulkan poin perak, itu akan memungkinkan pengaturan profil tulis melalui variabel lingkungan (misalnya DOCKER_COMPOSE_PROFILE = "tes")

ITU akan menjadi solusi terbaik. Tetapi menurut saya para pengembang tidak cenderung untuk meningkatkan kompleksitas ...

Saya ingin membangun gambar dasar, "memperpanjang" ini di docker-compose.yml yang sama dan memulai hanya gambar kedua, yang tidak dapat dilakukan dalam satu langkah saat ini. Dengan opsi 2 itu akan menjadi, tapi mungkin cara yang lebih baik dan lebih bersih adalah memiliki "membangun tahap" dan "tahap run", di mana pembuatan gambar dasar dilakukan. Saat ini saya harus menjalankan 2 perintah dan bukan hanya satu.

+1 @ drew-r # 1661

Apakah masalah ini akan diterapkan di beberapa titik atau hanya sesuatu yang tidak ingin dilakukan oleh developer? Alangkah baiknya mengetahui agar komunitas dapat mulai mencari solusi lain.

Ngomong-ngomong saya memilih opsi 2.

Terima kasih

1 untuk opsi 2.
Akankah itu menghormati dependensi eksplisit ... links etc?

Jika saya menentukan layanan mana yang akan ditampilkan dengan docker-compose up [service] , sangat jarang saya ingin memulai layanan apa pun selain layanan yang dipermasalahkan dan dependensinya.

Voting lain untuk opsi 2. Bahkan ada PR untuk itu (https://github.com/docker/compose/pull/3047) bahwa

Jika pengembang penulisan tidak ingin melakukan ini, mereka harus menyatakannya sekali dan untuk selamanya lalu menutup tiket dan menguncinya untuk mencegah komentar.

@msabramo compose pada dasarnya

Permintaan dilacak di repo mesin buruh pelabuhan https://github.com/docker/docker/issues/23880
Dari situlah keputusan / pekerjaan akan datang.

Saya menyarankan agar masalah ini ditutup.

@gittycat compose masih dapat memiliki opsi untuk memberi tahu engine untuk memulai layanan atau tidak. Ini adalah permintaan yang sangat valid.

Saya menyerah buruh pelabuhan pada produksi, ada banyak masalah. Kemudian saya bermigrasi ke gelandangan.

Voting lain untuk 2)

Voting lain untuk 2 dan 4.

Hanya untuk menunjukkan kasus penggunaan, beberapa layanan memiliki dependensi melingkar, kebutuhan untuk menghasilkan file konfigurasi, menjalankan rangkaian pengujian di antara banyak kemungkinan lainnya. Kami dapat memisahkannya dari Docker atau menggunakan alat lain tetapi menambahkan kerumitan yang tidak perlu untuk menyiapkan proyek.

Memiliki perintah sederhana untuk penyiapan dan / atau untuk pengujian akan membuat segalanya lebih bersih.

Voting lain untuk 2!

Saya telah membaca utas ini tetapi memutuskan untuk membuat posting baru (https://github.com/docker/compose/issues/4650), yang ditutup dan saya dirujuk ke sini. Hal yang ingin saya sampaikan adalah bahwa sementara sebagian besar diskusi di utas ini berkaitan dengan tanda untuk menonaktifkan penampung yang sedang berjalan, kasus penggunaan saya adalah status ketiga: membuat penampung.

Saya tidak hanya ingin mencegah penampung dijalankan tetapi juga tidak pernah dapat membuat penampung di tempat pertama (dalam kasus penggunaan saya, saya memiliki proses yang digerakkan oleh pengguna yang menyelesaikan ini)

@ekkis Saya ingin tahu tentang bagaimana itu bisa terjadi. Usee-case saya melibatkan merujuk ke image container utama dan mengkonfigurasi "tindakan" alternatif, dapat dilakukan dengan menggunakan sesuatu seperti bash tetapi lebih masuk akal untuk menggunakan Docker.

Apakah Anda akan berbaik hati memberikan lebih banyak detail tentang masalah Anda?

@frnco , tidak yakin saya mengerti apa yang Anda ingin detail lebih lanjut. ada kasus di mana Anda ingin membuat gambar tanpa perlu membuat penampung. kasus saya adalah salah satunya. Saya ingin gambar tertentu dibangun bersama dengan sekelompok gambar lain tetapi yang ini akan digunakan oleh proses yang saya tulis. Saya tidak ingin memiliki dua proses terpisah untuk membangun dan memiliki flag build-only dapat menyelesaikan masalah itu

@ekkis Saya sarankan Anda melihat # 963, sepertinya terkait dengan apa yang Anda cari.

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2

1 untuk opsi 2

: +1: untuk opsi # 2 dengan pertanyaan tentang perkiraan apa pun tentang fitur ini? Apa solusi terbaik? Sejauh yang bisa saya bayangkan perlu mencantumkan semua layanan saya seperti:

docker-compose up service1 service2 service3

... dan hilangkan yang tidak ingin saya mulai secara default

Adakah cara kita di komunitas open source dapat membantu menyumbangkan fitur yang tampaknya banyak diminta ini?

1 untuk opsi 2.
Cara untuk menentukan 'panggung' akan sangat bagus. Katakanlah, layanan hanya akan berjalan dalam produksi.

1 untuk opsi 2.

Beri suara untuk opsi 2

up pemfilteran perintah akan sempurna - docker-compose up service1 service3

: +1: untuk opsi 2 dan 4

Pada titik ini, tampaknya opsi 2 adalah yang diinginkan pengguna. Apa langkah selanjutnya untuk mewujudkannya?

Di sini untuk memberi +1 untuk opsi 2, menemukan masalah ini dengan harapan fungsi ini sudah ada.

+1 pada Opsi 2

... dan satu lagi +1 untuk opsi 2

1 untuk opsi 2

1 untuk Opsi 2 :-)

1 untuk opsi 2 dan 4

Halo semua,
Opsi +1 2

IMHO, opsi akan sangat berguna pada lingkungan lokal, ketika Anda memiliki aplikasi berbasis layanan mikro atau dengan arsitektur heksagonal; sebagai pengembang saya hanya dapat menjalankan elemen yang diperlukan untuk pekerjaan terdekat saya;

Opsi 2 adalah yang diinginkan sebagian besar pengguna. Apakah keputusan tentang ini masih harus dibuat atau pengembangan tentang ini sudah dimulai dan dilacak di tempat lain?

Saya pikir ketika saya menyelesaikan universitas dalam beberapa bulan dan memiliki lebih banyak waktu, akan jauh lebih cepat untuk mengimplementasikan fitur ini sendiri (walaupun saya belum belajar Python, yang menurut saya menulis adalah tulisan), tetapi saya melihatnya jumlah suara dan permintaan yang sangat besar, selama dua tahun, tanpa langkah maju, dan penerapan sendiri tampaknya menjadi solusi untuk 5 tahun ke depan (hingga fitur tersebut diterapkan secara resmi).

tentu saja +1000 untuk opsi 2

Opsi +1 2

Apakah ada bedanya jika saya memilih opsi 2? 'sepertinya tidak mungkin.

Komentar di sini menjadi semakin tajam akhir-akhir ini, dan tidak ada tanggapan baru yang benar-benar muncul, yang membuat saya mempertimbangkan untuk mengunci utas ini. Harap tetap sopan saat berinteraksi di sini.

Ini adalah posisi resmi terkini dari tim pengelola dalam masalah ini. Meskipun masih dalam pertimbangan apakah kami ingin menambahkan fitur ini, atau yang menyukainya, sebagai opsi kenyamanan, ini bukan prioritas karena alasan yang disorot, dan karena ada alat lain yang lebih cocok untuk itu.

@ shin- Sebelum kita mengunci ini, bisakah saya karena itu kita mendapatkan kejelasan jika komunitas berkehendak untuk pengembangan apakah tim inti akan menggabungkannya jika memenuhi standar tim? Di utas ada implementasi dan anggota masyarakat bersedia menyelesaikannya, mereka hanya mencari kepastian bahwa itu tidak akan menyia-nyiakan investasi mereka. Jika kami bisa mendapatkan umpan balik, saya akan melacak utas tersebut untuk dipindahkan untuk melihat apakah kami dapat memindahkannya ke penutupan.

@jimzucker Tidak - karena masalahnya di sini bukanlah implementasinya; implementasi dasar ini akan membutuhkan waktu setengah hari untuk pengembang rata-rata Anda. Yang menjadi perhatian kami di sini adalah masalah desain mendasar.

1. Apa itu layanan? Secara desain, layanan adalah proses yang berjalan lama dan terdefinisi dengan jelas yang berinteraksi dengan layanan lain untuk membentuk aplikasi. Itu adalah asumsi dasar bahwa Compose beroperasi di bawah dan ini memandu desain kami untuk sebagian besar, jika tidak semua fitur yang kami implementasikan.
2. Dengan definisi tersebut, "layanan yang tidak dimulai secara default" sebenarnya bukanlah layanan [1] - ini lebih merupakan tugas yang telah ditentukan sebelumnya, berjalan dalam wadah dan bertindak pada aplikasi, daripada menjadi bagian darinya.
3. Oleh karena itu salah (pada dasarnya menurut desain) menyebutnya sebagai layanan. Pada titik itu kita perlu mempertimbangkan untuk membuat tipe definisi baru di file Tulis Anda (saya akan menyebutnya "tugas" untuk singkatnya, terminologi yang tepat tidak masalah di sini).
4. Karena tugas pada dasarnya adalah proses yang berjalan singkat, tugas tersebut menggunakan serangkaian opsi yang berbeda dibandingkan dengan layanan. Misalnya, kita dapat mengetahui bahwa tugas tidak perlu mengekspos port [2]. Di sisi lain, opsi seperti file CID yang sebagian besar tidak berguna untuk layanan bisa sangat berguna untuk tugas.
5. Sekarang, di sebagian besar proyek, tugas cenderung memiliki rantai ketergantungan (itulah sebabnya di dunia tradisional non-kontainer, kita memiliki Makefiles) - jadi kita harus memiliki setidaknya implementasi dasar rantai ketergantungan, dengan paralelisme, dan mampu membedakan jika tugas build JAR yang selalu membutuhkan waktu 10 menit itu benar-benar perlu dijalankan lagi.
6. Kemudian, beberapa layanan benar-benar bergantung pada tugas yang telah dijalankan sebelum dapat dimulai, menambahkan tingkat kerumitan lain pada cara kami menghitung dan menangani dependensi.
7. Dan beberapa tugas memerlukan beberapa layanan agar dapat dijalankan (mis. Migrasi database).

Pada titik ini, ini telah menjadi bagian kode yang sama sekali baru yang mungkin cocok atau melampaui cmake dalam hal ruang lingkup dan kompleksitas. Inilah sebabnya mengapa kami telah menolak menerapkan ini begitu lama - sebagian karena ini bukanlah apa yang dirancang untuk Compose, tetapi juga karena kami [3] hanya tidak punya waktu atau sumber daya untuk mengimplementasikan atau mempertahankan fitur ini perlu menjadi benar-benar berguna bagi orang.

Semoga ini menjelaskan lebih banyak. Saya tahu orang-orang telah kecewa dan kecewa dengan tanggapan (atau ketiadaan) di utas ini, dan saya tidak yakin ini akan meringankan itu dengan cara apa pun, tetapi itu dia.

[1] Beberapa orang menyebutkan ingin memiliki "layanan opsional", tetapi itu bukan kasus penggunaan paling umum yang disebutkan di utas ini. Kebanyakan orang menginginkan fitur "tugas", sejauh yang saya tahu.
[2] Saya yakin seseorang akan membantah saya dengan contoh tugas yang perlu mengekspos port, yang hanya akan menunjukkan bahwa latihan memutuskan opsi mana yang berlaku untuk setiap set tidaklah sepele.
[3] Dan pada poin ini yang saya maksud adalah "Saya", karena saya satu-satunya pengelola yang secara aktif mengerjakan docker-compose saat ini.

@ shin- Saya mengerti intinya. Apa yang saya kejar adalah "layanan opsional" di catatan kaki Anda dan kasus penggunaan untuk itu, bukan gagasan tentang tugas, dapatkah kita setuju tentang bagaimana kita dapat memajukan titik itu karena itu adalah bagian dari utas yang saya coba perjuangkan dan tiket saya jelas di jalur yang ditutup untuk utas ini. Jika kita dapat memisahkannya dari poin yang telah Anda definisikan dengan jelas sebagai 'tugas', kami dapat membuat kemajuan. Saat orang-orang melakukan +1 untuk opsi 2 di bacaan saya, itu adalah untuk layanan opsional. Senang mengambil offline ini untuk berdiskusi dan kemudian kita dapat kembali ke forum, saya di [email protected]

@ shin- poin # 2 Anda salah. layanan adalah layanan terlepas dari apakah itu berjalan. Ada banyak sekali kasus penggunaan di mana layanan yang bergantung akan mengubah perilaku saat ketergantungan tidak tersedia, sehingga lapisan aplikasi Anda tidak boleh, tidak boleh, mengharuskan semua "layanan" tersedia setiap saat

jika Anda memikirkannya dalam istilah yang paling tradisional, pertimbangkan bahwa server web adalah "layanan" tetapi dapat dimatikan atau dikonfigurasi untuk tidak memulai secara default pada host tertentu tetapi tidak ada yang akan menganggapnya selain layanan

Saya rasa banyak orang yang meminta fitur ini tidak ingin menjalankan tugas tetapi layanan opsional. Misalnya, jika Anda memiliki sekumpulan layanan mikro yang berjalan sebagai wadah Docker dan Anda menerapkan semuanya sebagai keseluruhan layanan, mungkin suatu hari persyaratan Anda berubah dan Anda tidak perlu menjalankan semua wadah di semua server Anda karena untuk kasus itu Anda tidak membutuhkan fungsionalitas khusus yang termasuk dalam wadah non wajib.

Selain itu, menurut saya ini adalah fitur yang bagus untuk lingkungan pengembangan; jika Anda memperbaiki bug dalam wadah tertentu, Anda tidak perlu memulai semua wadah untuk itu.

Tepatnya, dengan bidang boolean sederhana kita dapat dengan mudah mengaktifkan / menonaktifkan layanan dari file .env dan menghindari mengedit file yaml.

@ekkis Saya pikir Anda agak membingungkan toleransi kesalahan dan dispensabilitas. Juga, lihat catatan kaki saya tentang subjek, di mana saya mengakui beberapa kasus penggunaan memang ada.

Semua orang: harap diingat bahwa jika beberapa layanan bersifat opsional untuk aplikasi Anda, hal ini sudah dapat ditangani dengan fitur terkini. Cara yang disarankan untuk melakukannya adalah memiliki file Tulis terpisah yang dapat disertakan atau dikecualikan menggunakan tanda -f . Mereka bukanlah argumen yang terlalu meyakinkan untuk menambahkan opsi ini.

@ shin- Saya menghargai Anda meluangkan waktu untuk berdialog dengan kami. Saya setuju ada beberapa cara untuk melakukannya, saat Anda menyarankan beberapa file yml, Anda juga dapat memberikan daftar layanan tetapi ini tidak nyaman dan menyebabkan kesalahan pengguna sehingga menimbulkan risiko operasional. Terutama dalam kasus produk komersial kami ingin mendistribusikan satu file tulis dan secara default mendapatkan perilaku umum yang diinginkan dan memberikan instruksi untuk opsi lanjutan, satu file membuat semua ini jauh lebih rapi untuk dev, CI / CD, dan distribusi. Penambahan variabel ENV dengan default sangat membantu kami dan telah menghilangkan kebutuhan untuk memiliki banyak file yml, ini akan menjadi satu langkah lagi untuk mengelola satu file yang menjelaskan penerapan.

Adakah bentuk kesediaan tim inti untuk menerima kontribusi di LMK ini?

@ shin , saya tidak merujuk pada toleransi kesalahan atau dispensabilitas. Saya hanya membuat poin tentang definisi "layanan", yaitu apakah layanan berjalan atau tidak tidak melekat dalam definisi tersebut.

@ shin- Saya sangat setuju dengan @ekkis : tidak dimulai _ secara default_ tidak melanggar definisi sebagai layanan, oleh karena itu poin 2. Anda adalah asumsi yang _tidak perlu_ benar dan begitu juga poin berurutan karena didasarkan pada asumsi 2.

Misalnya: ketika saya mengembangkan aplikasi menggunakan mysql DB, saya biasanya menetapkan _service_ phpmyadmin . Ini adalah layanan yang benar: port yang berjalan lama dan terbuka, bergantung pada layanan lain.
Tetapi saya tidak ingin memulai layanan ini _by default_ tetapi hanya _on demand_ / dalam pengembangan.
Saat ini saya menyadari hal ini dengan meletakkan layanan ini menjadi docker-compose.yml dan memulainya dengan menyediakan kedua file ke docker-compose - seperti yang Anda sarankan di atas.

Jadi, ya, sudah ada cara yang mungkin untuk mencapai ini; baik itu dengan membagi layanan menjadi beberapa file atau hanya menggunakan alat selain docker-compose . Tapi seperti yang sudah saya tulis di atas : masalah ini bukan tentang fitur / fungsi yang sepenuhnya baru atau konsep baru (yaitu _tasks_) tetapi tentang kenyamanan , terutama di lingkungan pengembangan .
Harus mengetik docker-compose -f docker-compose.yml -f docker-compose-tools.yml up sama sekali tidak nyaman dan karenanya docker-compose tidak memenuhi janjinya sendiri :

Bersama-sama, fitur-fitur ini memberikan cara yang nyaman bagi pengembang untuk memulai sebuah proyek. Tulis dapat mengurangi "panduan memulai developer" multi-halaman menjadi satu file Tulis yang dapat dibaca mesin dan beberapa perintah.

Layanan mana yang harus dimulai atau file yml akan digunakan di lingkungan mana yang biasanya ditemukan di _multi-halaman “panduan memulai pengembang [s]” _ - jika ditemukan sama sekali ...

Jadi menurut pendapat saya dan seperti yang ditulis @jimzucker, sebagian besar +1 di sini sebenarnya untuk "layanan opsional" daripada konsep tugas yang baru. Setidaknya semuanya lebih baik dengan boolean sederhana untuk menandai _service_ agar dimulai secara default atau tidak.

Karena PoC saya menunjukkan perubahan kode yang diperlukan - untuk "layanan opsional" - cukup mudah dikelola dan memberikan manfaat besar bagi kebanyakan orang di sini dalam kenyamanan. Opsi 2 - baca sebagai "_kemungkinan untuk menandai layanan opsional_" - adalah kompromi yang wajar untuk menyelesaikan masalah ini.

@ shin- tidakkah Anda setuju bahwa memberi pengguna kemungkinan untuk menandai layanan sebagai opsional - tetapi mereka tetap merupakan layanan - akan sangat membantu mereka?
Ketika dikurangi menjadi "menandai _services_ sebagai opsional / tidak dimulai secara default" akankah masalah / permintaan penarikan ini diterima dan digabungkan?

@ shin , untuk menambah poin @acran di atas, saya mungkin ingin membuat docker-compose hanya untuk membangun layanan tertentu karena layanan tersebut akan dijalankan oleh layanan lain yang menggunakan nama . menganggap bahwa setiap kali saya melakukan "up", saya mendapatkan banyak "layanan" bernama project_app_1 , project_otherapp_1 , dll. ini tidak masuk akal karena harus dijalankan menggunakan informasi dalam database (saya memiliki layanan master yang menjalankannya) . jadi saya selalu harus pergi membunuh mereka. jadi bagi saya flag NO_RUN atau BUILD_ONLY sangat masuk akal. ini akan memudahkan

@rhan

tidakkah Anda setuju bahwa memberikan kemungkinan kepada pengguna untuk menandai layanan sebagai opsional - tetapi mereka masih merupakan layanan - akan sangat membantu mereka?

Saya tidak setuju tentang seberapa banyak itu akan membantu - saya pikir "sangat" dilebih-lebihkan. Dalam contoh Anda, hanya memiliki docker-compose.phpmyadmin.yml yang secara opsional dapat disertakan tidak lebih memberatkan atau rumit (dalam hal instruksi "panduan pengembang") daripada menyetel variabel lingkungan / memodifikasi definisi layanan di dalam file utama.
Saya juga mempertimbangkan pengorbanan dari memberikan "senjata" kepada pengembang jika tidak terlalu diperlukan.

Ketika direduksi menjadi "menandai layanan sebagai opsional / tidak dimulai secara default", apakah masalah / permintaan penarikan ini akan diterima dan digabungkan?

Lihat di atas - segera setelah fitur ini tersedia, orang-orang akan mulai menggunakannya untuk hal-hal selain tujuan yang dimaksudkan, dan mengharapkan kami untuk menerapkan kumpulan fitur baru untuk mendukungnya. Juga cc @jimzucker ; Saat ini saya tidak dapat memikirkan implementasi yang akan mencegah skenario ini terungkap. Jika saya bisa, masalah ini akan ditutup sejak lama.

@ekkis Jika Anda tidak pernah ingin memulai layanan itu sendiri, mengapa sebenarnya masalah untuk mengisolasi mereka dalam file terpisah? Saya benar-benar bingung mengapa ini seperti digantung di sini.

@shin jika buruh pelabuhan-compose.yml dapat digunakan untuk membangun layanan, itu adalah alat yang paling berguna dalam memusatkan proses pembangunan saya. sebenarnya sangat masuk akal bahwa saya mungkin ingin (secara bersyarat) membangun layanan sebelum menjalankannya, dan saya memuji fungsionalitas itu

jadi file docker-compose juga merupakan makefile saya. tetapi hanya karena saya membangun sesuatu tidak berarti saya ingin menjalankannya. tidak masuk akal bagi buruh pelabuhan-menulis untuk berasumsi bahwa saya ingin menjalankan sebuah layanan, menciptakan nama untuk itu, dan menjalankannya tanpa parameter / variabel lingkungan / dll.

terus terang saya tidak yakin saya mengerti apa yang menjadi keberatan dari tambalan sederhana ini. itu akan sangat berguna bagi saya

Saya dengan jelas menunjukkan di posting saya

@ shin-

Dalam contoh Anda, hanya memiliki docker-compose.phpmyadmin.yml yang secara opsional dapat disertakan tidak lebih memberatkan atau kompleks (dalam hal instruksi "panduan pengembang") daripada menyetel variabel lingkungan / memodifikasi definisi layanan di dalam file utama.

Sebenarnya saya belum berpikir untuk melibatkan variabel lingkungan di sini. Alur kerja yang saya inginkan akhirnya diizinkan "layanan opsional" adalah sebagai berikut:

• Saya menyalin / mengkloning proyek baru
• Saya melihat ada file (tunggal) docker-compose.yml di dalamnya, oleh karena itu saya tahu, yang harus saya lakukan hanyalah menjalankan docker-compose up dan aplikasi dibangun dan dijalankan
• Sekarang saya ingin memulai salah satu layanan opsional untuk tujuan pengembangan (mis. Debugging tambahan, phpMyAdmin). Yang harus saya lakukan adalah docker-compose up phpmyadmin .

Bagi saya ini _much_ lebih nyaman daripada menggunakan beberapa file docker-compose.yml , dan seperti yang saya pahami untuk kebanyakan orang di sini juga. Manfaat memiliki "layanan opsional" di sini adalah

• untuk pengembang tidak harus menduplikasi apa pun di antara beberapa file atau harus mempertimbangkan dengan cermat definisi mana yang akan dimasukkan ke file mana, tetapi hanya harus menyetel satu bendera boolean ( auto_up: false ) pada layanan
• bagi pengguna yang tidak harus mengetahui / mengingat file mana yang akan disertakan untuk layanan mana: apakah saya perlu menjalankan
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up atau bahkan
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ?
  
  
• sebagai gantinya, satu-satunya hal yang pengguna perlu _know_ adalah bahwa ada layanan bernama phpmyadmin dan pengguna langsung tahu bagaimana memulainya.

Lihat di atas - segera setelah fitur ini tersedia, orang-orang akan mulai menggunakannya untuk hal-hal selain tujuan yang dimaksudkan, dan mengharapkan kami untuk menerapkan kumpulan fitur baru untuk mendukungnya

Jangan salah paham, saya tidak hanya memahami kekhawatiran Anda di sini tetapi juga menyetujuinya: akan selalu ada pengguna yang membengkokkan fitur ini - atau lainnya (!) - agar sesuai dengan alur kerja yang mereka inginkan meskipun fitur tersebut tidak pernah dimaksudkan digunakan seperti itu.
TAPI untuk setiap permintaan tentang "layanan opsional" fitur yang hilang dari "tugas", Anda dapat _then_ dengan mudah membantah bahwa layanan bukanlah tugas dan tugas perlu diperkenalkan sebagai konsep baru terlebih dahulu dan oleh karena itu belum didukung (belum). Yaitu sesuatu yang lebih dari sekedar menandai layanan sebagai opsional adalah langkah menuju konsep tugas (misalnya opsi 4) dan ada jalan pintas yang jelas antara.

Dengan fitur menandai _service_ sebagai opsional, kami masih berada di sisi kanan pemotongan itu. "Fitur itu sendiri tidak terlalu rumit untuk diterapkan tetapi _might_ menggoda pengguna untuk menggunakannya secara salah" saat ini menjadi satu-satunya argumen yang nyata (meskipun valid!) Yang menentang fitur ini cukup tidak memuaskan sebagai alasan untuk tidak mengimplementasikannya - setidaknya untuk pengguna yang bisa mendapatkan banyak kenyamanan saat menggunakannya dengan cara yang benar ™.

Saya siap untuk mengubah peringkat permintaan tarik saya # 3047 ke master saat ini dan melakukan pemolesan yang diperlukan agar ini diterima, harap beri tahu saya;)

Kasus penggunaan saya adalah kami tidak mendorong semua gambar kami ke hub buruh pelabuhan atau dermaga, kami juga tidak memiliki registri sendiri, dan dapat menandai layanan sebagai tidak-untuk-dijalankan-oleh-default berarti kami bisa memiliki gambar dasar yang ditentukan dalam docker-compose.yml yang tidak dapat dimulai, dan kemudian penampung lain menggunakan atau membangunnya.

Saya akan cenderung menggunakan garpu docker-compose yang mengimplementasikan fitur ini hanya untuk fitur tunggal ini.

@ shin- Meskipun saya pikir kita semua memahami maksud Anda dan bersimpati dengannya, saya tidak berpikir "itu mungkin disalahgunakan" adalah argumen yang baik untuk sesuatu dengan - jelas - banyak kasus penggunaan yang layak. Tentu saja _akan_ disalahgunakan. Itulah tepatnya bagaimana perangkat lunak dan ide-ide baru tumbuh; keluar dari penggunaan teknologi tidak sepenuhnya sebagaimana mestinya. Web tidak akan seperti sekarang ini jika kita tidak menyalahgunakan semua teknologi yang disediakan selama 25 tahun terakhir.

Bagaimanapun.
Menurut Anda - sederhana - perbedaan antara layanan dan tugas adalah waktu hidup. Masuk akal, dan saya mengerti Anda melihatnya sebagai dua konsep yang berbeda dan merasa itu adalah potensi cacing. Tetapi perbedaan ini tidak diklarifikasi atau dijelaskan dalam dokumentasi. Juga tidak ada yang menunjukkan bahwa buruh pelabuhan tidak dimaksudkan untuk digunakan untuk memutar proses temporal.
Yang ingin saya katakan adalah bahwa jika tim buruh pelabuhan memiliki pendirian yang kuat tentang hal ini, hal itu harus dijelaskan sejak awal.
Juga. Tugas atau layanan, jelas ada tumpang tindih. Dan menandai layanan sebagai opsional jelas bukan sesuatu yang dimiliki sisi tugas secara unik.
Dari sudut pandang praktis saya sangat setuju dengan @acran - memiliki satu file docker-compose jauh lebih baik DX, menyederhanakan banyak hal dan lebih sedikit rawan kesalahan daripada memiliki beberapa file docker-compose.

Hehe, saya ingat diskusi sengit yang kami lakukan ketika kami melobi untuk mengizinkan "browser" menampilkan gambar, dengan argumen utama lawan adalah bahwa itu disebut protokol transfer teks hiper.
Maaf untuk kenangan PL tentang kentut tua.

@ shin- jika docker-compose tidak boleh digunakan sebagai makefile, maka itu seharusnya tidak menyediakan fungsionalitas makefile. jika memungkinkan saya untuk membangun proyek saya (bravo!) maka mengambil posisi bahwa itu bukan makefile adalah hal yang menggelikan

@ shin- lihat, kalian tidak perlu mengimplementasikan fitur apa pun yang tidak Anda inginkan, tidak peduli seberapa tidak masuk akal alasan Anda, atau seberapa berguna fitur tersebut. hanya saja hal itu membuat alat tersebut kurang bermanfaat bagi kita yang menggunakannya. kami adalah penggunanya, kami tahu kasus penggunaan - dan alat hanya berguna, berharga karena mereka melayani kasus penggunaan

ini bagi saya hanya gangguan kecil, saya harus secara manual membunuh banyak hal yang muncul tanpa alasan yang baik _setiap kali saya meningkatkan layanan saya_. bagi orang lain itu mungkin merupakan penghalang, iritasi akan bervariasi dalam tingkat keparahan

Saya mengerti bahwa posisi resminya adalah kita harus menggunakan dobi, meskipun itu berlebihan untuk apa yang kita butuhkan. tetapi posisi resmi itu tidak menjelaskan dasar keengganan Anda untuk menerima PR yang berguna. kita masih bisa menggunakan dobi ketika permintaan pada buruh pelabuhan-menulis terlalu besar atau tumpang tindih cukup untuk bermigrasi, tapi ini adalah perubahan yang sangat kecil yang akan membuat hidup kita jauh lebih baik

dan kebetulan, saya tidak bersikap "keras" tetapi mengunci utas untuk mencegah diskusi lebih lanjut hanya akan menjadi tidak demokratis dan otoriter. open source dibangun di atas prinsip keterbukaan dan saya akan sedih melihat proyek ini dikelola menggunakan sensor dan taktik diktator

@rysiekpl Ini adalah masalah yang ingin kami https://github.com/docker/cli/pull/452 (setelah sintaks dipertimbangkan, ini akan masuk ke Compose dan v2 as baik)

@creynders Saya pikir itu sedikit salah karakterisasi - tidak ada yang mengatakan bahwa layanan opsional tidak boleh ada (dan sebenarnya, seperti yang saya tunjukkan, ada cara untuk mendeklarasikannya dengan menggunakan file terpisah). Ini lebih mirip dengan memperdebatkan apakah menutup tag <img> secara eksplisit tidak valid dan apakah browser khusus kita harus mendukungnya atau tidak.

Juga, ke poin Anda:

Tetapi perbedaan ini tidak diklarifikasi atau dijelaskan dalam dokumentasi. Juga tidak ada yang menunjukkan bahwa buruh pelabuhan tidak dimaksudkan untuk digunakan untuk memutar proses temporal.

Ini sebenarnya adalah paragraf pertama dari halaman https://docs.docker.com/compose/overview/ (penekanan saya):

Compose adalah alat untuk menentukan dan menjalankan aplikasi Docker multi-container. Dengan Tulis, Anda menggunakan file Tulis untuk mengonfigurasi layanan aplikasi Anda. Kemudian, dengan menggunakan satu perintah, Anda membuat dan memulai semua layanan dari konfigurasi Anda.

@ekkis Saya sangat senang bahwa Compose sangat membantu proyek Anda! Saya harap saya tidak dianggap tidak tulus dalam semua ini, tidak apa-apa jika itu cara Anda ingin menggunakan perangkat lunak. Apa yang saya katakan, bagaimanapun, adalah bahwa melangkah lebih jauh ke arah itu mungkin akan membuatnya lebih buruk dalam jangka panjang. Kita semua tahu apa yang terjadi pada aplikasi yang mencoba melakukan terlalu banyak hal (meskipun saya kira Emacs melakukannya: stuck_out_tongue:)

Saya tidak berpikir saya menjadi "otoriter", tetapi mungkin saya tidak mengekspresikan diri saya dengan benar. Niat saya adalah mendorong orang untuk tetap bersikap sopan dan positif dalam interaksi mereka. Utasnya masih tidak terkunci dan akan terus berlaku selama orang menahan diri untuk tidak bersikap kejam atau tidak sopan.

Anda membuat dan memulai semua layanan dari konfigurasi Anda.

dan saya kira anggapan kami adalah bahwa seharusnya membaca "buat dan / atau mulai", meskipun agar adil untuk bahasa yang tidak perlu menunjukkan OR karena tersirat dalam DAN. dengan kata lain, memang benar bahwa Anda berdua dapat membuat dan memulai layanan, tetapi tidak ada implikasi bahwa layanan harus melakukan keduanya

Kita semua tahu apa yang terjadi pada aplikasi yang mencoba melakukan terlalu banyak hal

ya, saya menghargai bahwa Anda mengelola perbatasan domain

Saya tidak berpikir saya menjadi "otoriter"

Saya suka gerakan open source. kita dapat memiliki ketidaksepakatan kita tetapi kita masih dalam hal ini bersama-sama. perang dalam komunitas bitcoin sangat mengerikan dan saya rasa saya masih belum pulih dari itu, jadi terima kasih telah tetap berada di sisi kesopanan.

Sebagai pemikiran perpisahan, saya akan meminta Anda meninjau ulang https://github.com/docker/compose/issues/4650 yang tidak sama dengan permintaan di utas ini (seperti yang Anda tunjukkan saat menutupnya) tetapi mengakomodasi penggunaan saya kasus, yaitu bahwa bendera yang dibahas di sini bukanlah biner tetapi trinary

Saya sangat menyukai gagasan untuk mendefinisikan banyak file. Namun memasukkan semua file dengan multi -f termasuk yang asli tampaknya berlebihan.

Sebenarnya ada cara yang lebih praktis, yang berhasil untuk saya (lihat PS di bawah): letakkan semua layanan yang tidak ingin Anda jalankan di docker-compose.override.yml . Dan gunakan docker compose -f docker-compose.yml up untuk startup normal (perhatikan bahwa ini adalah perintah satu kali). Pada semua panggilan berurutan, penggantian akan bersumber ...

Secara keseluruhan ini semua sangat tidak intuitif dan sedikit tidak memuaskan. Menambahkan tambahan:

• opsi untuk menonaktifkan layanan masuk akal terutama untuk penggantian yang lebih kompleks

• Opsi -f minimal tetapi tidak terlalu intuitif, opsi -F <name> yang hanya menambahkan penggantian tambahan akan sangat ramah (mis. Docker-compose..yml. Alternatif akan menggunakansebagai direktori di mana semua file .yml bersumber: bersama dengan symlink, ini akan sama kuatnya dengan /etc/apache/sites.available -> /etc/apache/sites.enabled

Di sisi lain: siapa pun dapat menyediakan skrip (fungsi) pembungkus simpe untuk shell mereka untuk meniru perilaku ini ...

PS: kasus penggunaan saya adalah saya mendefinisikan debugger sebagai layanan. Tentunya layanan ini tidak diperlukan setiap saat tetapi membutuhkan tautan (juga untuk alasan keamanan) agar berfungsi dengan benar.

Kasus penggunaan lain yang membuat Opsi 2 sangat bagus:

Katakanlah Anda memiliki tim orang yang mengerjakan proyek yang sama. Beberapa dari mereka memiliki akses ke layanan terkelola AWS, tetapi beberapa dari mereka perlu menjalankan sumber daya yang sesuai sebagai kontainer lokal. Jadi, bergantung pada alur kerja saya, saya akan _always_ atau _never_ memerlukan wadah Redis dan MySQL di konstelasi penulisan saya.

Saya akan langsung menyatakan bahwa mengelola beberapa file tulis adalah hal bodoh untuk kasus penggunaan ini. Jumlah tumpang tindih itu lucu. Mempertahankan beberapa file sangatlah mudah - mereka _akan_ tidak sinkron dan menyebabkan kebingungan. Sejujurnya saya sedikit terkejut bahwa ada orang yang menganggap opsi itu serius untuk kasus penggunaan _ apa saja_.

Mampu dengan cepat mengaktifkan dan menonaktifkan layanan, tanpa mengomentari blok besar konfigurasi (canggung di YAML, sangat berantakan jika tidak sengaja dilakukan), sangat bagus sendiri. Tetapi jika menulis suatu hari nanti mendapatkan kemampuan untuk menginterpolasi variabel ke dalam konfigurasi, fitur ini secara otomatis menjadi lebih kuat secara eksponensial. Sampai saat itu, ini _merely_ sangat berguna.

Sepenuhnya setuju dengan @campadrenalin.

Seluruh diskusi ini, seperti yang saya pahami, pada dasarnya adalah sejumlah besar orang yang memberikan sejumlah besar alasan yang sangat bagus untuk menerapkan Opsi 2, dan para pengembang menolak karena seseorang secara hipotetis berpotensi salah menafsirkan keberadaan fitur ini dan meminta beberapa fitur lain yang tidak terkait .

OT:

Tetapi jika menulis suatu hari nanti mendapatkan kemampuan untuk menginterpolasi variabel ke dalam konfigurasi, fitur ini secara otomatis menjadi lebih kuat secara eksponensial.

Bukankah fitur ini sudah lama tersedia? Lihat https://docs.docker.com/compose/compose-file/#variable -substitution. Saya menggunakannya untuk mengizinkan kustomisasi lingkungan Compose dev kami dengan menggunakan file .env - mis. Lokasi kode sumber, pemetaan port, dll. Sejak buat file versi 2.1 bahkan variabel gaya shell default ( ${VARIABLE:-default} / ${VARIABLE-default ) didukung.

Seluruh diskusi ini, seperti yang saya pahami, pada dasarnya adalah sejumlah besar orang yang memberikan sejumlah besar alasan yang sangat bagus untuk menerapkan Opsi 2, dan para pengembang menolak karena seseorang secara hipotetis berpotensi salah menafsirkan keberadaan fitur ini dan meminta beberapa fitur lain yang tidak terkait .

Saya menemukan ini menjadi - mungkin agak kasar nadanya, tetapi pada dasarnya valid - ringkasan yang sangat bagus oleh @rysiekpl.
Jadi, @ shin-, apakah kita sudah mendekati keputusan terkait masalah ini? Apakah akan menutupnya saja atau menerapkan / menerima PR untuk opsi 2?

Saya benar-benar melihat dan memahami kekhawatiran Anda, tetapi juga melihat keuntungannya lebih besar daripada risiko seseorang yang berpotensi menyalahgunakan ini, karena ini adalah perubahan yang agak kecil tetapi menawarkan lebih banyak kemungkinan kepada banyak orang untuk lebih banyak alur kerja _convenient_.

Karena docker-compose tampaknya dihentikan dalam jangka panjang demi tumpukan pekerja pelabuhan, saya menyarankan semua orang pindah ke format v3 baru dan alat docker stack sesegera mungkin.

Menggunakan tumpukan pada sekumpulan (bahkan pada 1 node), Anda dapat menentukan ini:

        deploy:
            mode: replicated
            replicas: 0

Memiliki nol replika pada dasarnya menonaktifkan layanan agar tidak berjalan.

Anda hanya memerlukan beberapa alat lain untuk menghasilkan yml tersebut jika Anda ingin menerapkan substitusi variabel lingkungan, seperti envsubst.

Anda kemudian dapat menggunakan placeholder di yml Anda:

        deploy:
            mode: replicated
            replicas: ${R}

Dan proses dengan cara ini:

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

Jadi, jika docker-compose akan dihentikan dalam jangka panjang, apa sebenarnya masalah menggabungkan permintaan tarik yang sudah ada di luar sana ? Maksud saya, jika docker-compose berjalan sesuai rencana, bagaimana "seseorang akan meminta fitur aneh" menjadi masalah nyata?

Sebagai buruh pelabuhan-menulis tampaknya jatuh dalam jangka panjang mendukung tumpukan buruh pelabuhan

Jadi, jika docker-compose tidak akan digunakan lagi dalam jangka panjang

tunggu, wat? docker-compose sangat penting bagi banyak orang untuk alur kerja pengembangan mereka, yang hampir tidak membutuhkan swarm manager. Bisakah Anda menunjukkan kepada saya beberapa pernyataan resmi oleh Docker tentang hal ini?

Saya mungkin salah membaca ini, tapi sepertinya buruh pelabuhan dan tumpukan buruh pelabuhan sangat erat hubungannya dengan layanan awan buruh pelabuhan. Apakah hal-hal ini dapat dikonfigurasi pada sistem offline mandiri?

Apakah hal-hal ini dapat dikonfigurasi pada sistem offline mandiri

ya, Anda dapat menggunakannya secara offline.

Bagi saya, sepertinya stack di docker-swarm pada akhirnya akan menjadi superset dari fitur-fitur docker-compose. Saya pikir file deskriptornya sudah sangat mirip. Semoga transisi ini tidak terlalu sulit. Gangguan terbesar yang dapat saya lihat adalah mengelola gerombolan secara terpisah dari tumpukan. Lebih banyak pekerjaan overhead untuk saya karena saya tidak tertarik menjalankan aplikasi yang dibuat di lebih dari satu node.

Atau mungkin saya salah paham semuanya ...?

+1 pada opsi 2!
Dan saya pikir penurunan jumlah buruh pelabuhan yang mendukung tumpukan kelompok akan menjadi kerugian besar bagi komunitas. Docker compose sangat sederhana dan mudah digunakan !!

@tberne Saya setuju dengan itu. buruh pelabuhan-menulis sederhana dan sederhana adalah hal yang baik. kita harus memilih untuk menyimpannya

Heh, diskusi yang panjang! Jangan terlalu memperhatikan komentar ini, hanya dua sen saya.

Awalnya saya setuju dengan mayoritas untuk menambahkan semacam bendera enabled .
Kemudian saya melihat proposisi untuk definisi cabang menurut kelompok dan menganggapnya sebagai ide yang bagus.
Kemudian saya membaca tentang Dobi, mencobanya, memastikan bahwa itu tidak dapat digunakan dalam proyek saya sekarang dan terus membaca.
Kemudian saya membaca argumen @ shin- dan menganggapnya cukup baik, meskipun saya juga setuju dengan beberapa argumen tandingan.

Solusi saya saat ini adalah membuat beberapa yamls docker-compose dan menulis beberapa skrip bash wrapping agar tidak menjalankan docker-compose dengan tangan.

Misalnya, inilah cara saya menjalankan container yang menjalankan situs web ( ./docker/scripts/up script):

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

+1 Besar untuk Opsi 2 atau 3.

1 untuk Opsi 2 atau 3.

Juga konsep "kelompok" yang diusulkan terdengar menarik!

1 untuk opsi 2

_Ada begitu banyak +1 on option x , sehingga saya bahkan tidak dapat menemukan pernyataan aslinya. Silakan gunakan tombol reaksi di bawah posting sebagai gantinya._

Untuk menambahkan ide baru:

Tidak bisakah kita menetapkan skala default ke 0 ?

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

Anda hanya harus melakukan opsi 2 (tapi mungkin nostart sebagai gantinya atau sesuatu) karena orang telah menunggu bertahun-tahun sekarang, kemudian membungkus docker-compose dengan manajer konfigurasi mereka sendiri karena alatnya terlalu terbatas, yang mengalahkan intinya karena melakukan apa yang harus ditulis oleh buruh pelabuhan sedang melakukan. Dalam dua tahun, seseorang juga bisa membuat karya tulis buruh pelabuhan yang lebih kuat. Sudah sering kali masalah ini terbuka.

Dalam jangka panjang harus ada beberapa pertimbangan tentang pengelompokan opsi yang benar. Beberapa hanya relevan untuk dibangun, beberapa hanya untuk dijalankan dan beberapa saling menguntungkan (Anda benar-benar menginginkan lapisan bersarang setidaknya untuk dijalankan atau hanya memisahkan dan memiliki bagian build, masalah diselesaikan). Saat ini meskipun banyak hal yang bermasalah dalam konfigurasi, saya semua hanya membuat ulang semuanya dalam versi 5 tetapi memperbaikinya saat itu (terutama dengan mewakili yang sebenarnya pada domain tingkat teknis daripada mencoba membuatnya memetakan penggunaan domain berbasis atau terlalu sederhana, sebagai gantinya buat lapisan konfigurasi untuk tujuan tersebut di atas yang benar, Anda tidak dapat melakukannya secara terbalik). Saya pikir karena keadaan itu, perbaikan cepat dibenarkan.

1 untuk opsi 2 atau 4

Jika tidak ada rencana untuk menambahkan fitur ini saat ini, saya ingin cara menjalankan layanan (atau tugas) seperti itu dalam komposisi ditulis di dokumen docker-compose.

Ini adalah utas lama, dan saya setuju bahwa docker-compose tidak akan peduli tentang _services yang tidak akan berjalan dari start_.

Tetapi saya juga biasanya menambahkan layanan test , jadi inilah yang saya lakukan:

1. Ganti entrypoint layanan.

2. Di entrypoint , periksa apakah ada tty tersedia ( docker-compose run menggunakan --tty secara default sedangkan up tidak).

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   Ini akan selalu membuat layanan keluar ketika dijalankan tanpa tty (dengan docker-compose up , misalnya) sementara masih berjalan seperti yang diharapkan dengan docker-compose run

@paulodiovani Itu lebih terlihat seperti peretasan daripada solusi.

+1 untuk permintaan fitur.
hacks seperti memiliki perintah yang tidak berarti bahkan jika wadah tidak berjalan, itu masih harus dibangun, diinisialisasi dll ..

Saya menyelesaikan ini dalam proyek saya dengan menyediakan skrip bash sederhana yang memanggil perintah docker-compose sesuai berdasarkan argumen yang diberikan.

Sekarang jika saya melakukan ./docker-compose.sh -e testing up , hasilnya sama seperti jika saya melakukan docker-compose -f docker-compose.yml -f docker-compose.testing.yml up .
Jika saya melakukan ./docker-compose.sh up , saya mendapatkan, seperti yang Anda harapkan, docker-compose up .

Oleh karena itu, opsi -e ${environment} (kependekan dari --env ) pada dasarnya adalah alias untuk -f docker-compose.yml -f docker.compose.${environment}.yml . Ini menghasilkan docker-compose.yml menjadi file penulisan dasar / default dan file seperti docker-compose.testing.yml menjadi ekstensinya.

Ini agak memecahkan masalah @acran dari pengguna yang tidak mengetahui file mana yang akan disertakan (dan dalam urutan yang mana) ke perintah docker-compose dengan menerapkan default yang waras. Ini bukan solusi yang sangat kuat karena beberapa mungkin menggunakan kombinasi file penulisan yang lebih kompleks, tetapi saya pikir docker-compose harus dapat melakukan sesuatu yang serupa. Kebanyakan file docker-compose kemungkinan besar dimulai dengan docker-compose. dan diakhiri dengan .yml , jadi mengapa saya selalu harus mengetikkan perintah yang begitu panjang ( docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ) jika saya hanya memerlukan satu layanan tambahan untuk lingkungan pengujian saya?

Tidak perlu envsubst, docker-compose config melakukan variabel lingkungan dan kemudian tumpukan pekerja pelabuhan mengambilnya dari stdin:

docker-compose config | docker stack deploy --prune --compose-file -

Mari Anda menggunakan substitusi .env docker-compose juga.

@kogli Saya pikir masalahnya di sini adalah memilih opsi. Semua memiliki Pro dan Kontra. Seperti yang saya katakan sebelumnya:

Setiap solusi akan lebih baik untuk beberapa kasus penggunaan, dan lebih buruk (Atau bahkan tidak berguna) untuk orang lain. Jika sesuatu diimplementasikan, pelihara itu selamanya, jadi saya yakin mereka bijaksana dalam meluangkan waktu dengannya.

@ shin- Saya rasa kaulah yang bertanya: Apakah masuk akal untuk mempertimbangkan ini? Mempertimbangkan posisi tim saat ini, betapa sulitnya mendesainnya, dan banyaknya alat di luar sana, bukankah lebih mudah untuk memberi tahu orang-orang bahwa ini tidak akan terjadi? Kebanyakan orang, jika tidak semua orang yang berkomentar di sini menemukan cara untuk menghadapinya.

Menutup ini tampaknya cukup bagus, ditambah Anda dapat fokus pada hal-hal yang penting, dan tidak ada yang bertanya-tanya apakah mereka harus membuat permintaan tarik dan bagaimana memenuhi semua kebutuhan itu pada saat yang bersamaan. Mereka bisa pergi membangun sesuatu yang lain, dan bahkan mungkin menerbitkannya untuk membantu orang lain.

Sekadar catatan : Solusi saya tidak sempurna, tetapi jauh lebih baik daripada 2 hari yang saya butuhkan untuk menginstal dependensi dan memperbaiki banyak hal dan membuat proyek berjalan (dan sudah menggunakan Docker). Hanya 3 perintah, dengan Docker dan Docker Compose sebagai satu-satunya dependensi. Ya, ada lebih banyak kode daripada yang saya inginkan. Ya, ada perintah buruk untuk menjalankan perintah. Dan ya, ada sedikit lagi yang perlu diingat. Halaman Wiki mencakup itu. Syukurlah, jika saya sendiri yang mengatakannya, yang berarti Docker Compose telah melakukan tugasnya , saya juga perlu sesuatu yang lain .

Intinya adalah: Jika di luar ruang lingkup, hanya membuang-buang waktu untuk terus mendiskusikannya. Banyak orang hanya berhenti di sini untuk bertanya tentang ini dan memberikan pendapat mereka, sebelum mencoba memutuskan apa yang harus dilakukan. Mereka masih akan menemukan atau membangun sesuatu yang lain jika ini ditutup, lebih cepat. Dan Anda mendapatkan satu utas lebih sedikit untuk dijaga.

Sunting: Hanya memikirkan cara yang baik untuk mengatakannya: Jika tidak ada kriteria yang jelas untuk menerima PR dan tidak ada seorang pun di tim inti yang terlibat atau berencana untuk melihatnya di masa mendatang, itu bukan " masalah ", hanya sebuah ide.

Saya tidak melihat alasan untuk mengacaukan daftar masalah, saya yakin banyak ide di sini bagus, tetapi saya pikir ide itu ada di tempat lain, untuk kebaikan atau keburukan. Sudah hampir 3 tahun, dan jika suatu saat situasinya berubah, Anda selalu dapat membuka kembali ini, atau membuka isu baru tentangnya.

Fitur ini membutuhkan waktu satu hari untuk diterapkan karena sangat sederhana. Namun, setelah 2 tahun berdiskusi, tetap tidak ada. Sedih.

@rubycut Ya, itulah yang terjadi ketika apa yang disebut "prinsip yang lebih tinggi" mengambil alih dari kegunaan dan keramahan pengguna. Saya sepenuhnya memahami bahwa pengembang tidak ingin menyumbat produk dengan fitur yang tidak logis. Namun, fitur yang sangat diminta ini tampaknya masuk akal. Sangat menyedihkan ketika para pengembang mengira mereka lebih tahu daripada penggunanya. (Sekali lagi, mereka biasanya melakukannya. Tetapi tidak selalu. Tidak kali ini.)

@rubycut Talk itu murah, tunjukkan kodenya. Jika bisa, kirim PR Anda, jika tidak bisa, laporkan saja dan tunggu.

@wangwenpei Apakah kamu bercanda? Pertama-tama, Anda bukan pengelola proyek ini. Jika pengelola menerima gagasan ini, dan memberi tag "bantuan diinginkan", saya yakin seseorang dapat menyumbangkan permintaan tarik. Tetapi mereka mengatakan bahwa mereka tidak tertarik. Jadi, mengapa repot-repot menarik permintaan jika tidak diterima.

Untuk diketahui, "kode" sudah ada: # 3047

@wangwenpei baik, # 3047, ada permintaan tarik ...
menunggu untuk mendapatkan setidaknya beberapa umpan balik selama lebih dari dua tahun sekarang. Itu ditutup baru-baru ini

untuk alasan yang disorot di https://github.com/docker/compose/issues/1896#issuecomment -322285976

yang cukup membuat saya marah untuk jujur ​​karena argumen yang diberikan di https://github.com/docker/compose/issues/1896#issuecomment -322285976 sama sekali tidak berhubungan dengan pull request:

1. Apa itu layanan? Secara desain, layanan adalah proses yang berjalan lama dan terdefinisi dengan jelas yang berinteraksi dengan layanan lain untuk membentuk aplikasi. Itu adalah asumsi dasar bahwa Compose beroperasi di bawah dan ini memandu desain kami untuk sebagian besar, jika tidak semua fitur yang kami implementasikan.
2. Dengan definisi tersebut, "layanan yang tidak dimulai secara default" sebenarnya bukanlah layanan [1] - ini lebih merupakan tugas yang telah ditentukan sebelumnya, berjalan dalam wadah dan bertindak pada aplikasi, daripada menjadi bagian darinya.

Saya tidak melihat pernyataan By that definition, a "service that is not started by default" is not really a service benar. Layanan yang tidak dimulai secara default hanyalah layanan yang tidak dimulai secara default, tidak lebih, tidak kurang pada saat ini. Dimulainya secara default atau tidak tidak mengatakan apa pun tentang layanan yang berjalan lama atau tidak, menjadi bagian dari aplikasi atau tidak, hanya mengatakan bahwa tidak akan dimulai secara default.

Dan itulah yang sebenarnya dilakukan oleh perubahan dalam permintaan tarik: tambahkan kemampuan untuk menandai layanan yang akan dimulai secara default atau tidak.
Tidak perlu memperkenalkan konsep baru seperti tugas untuk melakukan ini. Faktanya semua argumen lain di https://github.com/docker/compose/issues/1896#issuecomment -322285976 mengikuti dari premis palsu 2. dan dengan demikian tidak berlaku untuk permintaan pull yang tidak mencoba melakukan apa pun lain.

Hanya untuk kelengkapan:

[1] Beberapa orang menyebutkan ingin memiliki "layanan opsional", tetapi itu bukan kasus penggunaan paling umum yang disebutkan di utas ini. Kebanyakan orang menginginkan fitur "tugas", sejauh yang saya tahu.

Ya, ada contoh tugas satu kali, tetapi ada juga contoh untuk layanan _real_ menurut definisi Anda, yaitu kasus penggunaan yang sah untuk fitur ini.
Mampu menggunakan ini untuk _also_ menjalankan tugas satu kali saya tidak dapat benar-benar menerima sebagai argumen yang valid terhadap ini. Hal ini sudah dimungkinkan untuk menentukan _service_ yang tidak lama berjalan, tidak mengekspos port dan bukan merupakan bagian penting dari aplikasi dalam benar-benar berlaku docker-compose.yml .

Sebenarnya ini juga salah satu solusi yang disarankan! Pisahkan saja _tugas_ menjadi docker-compose.yml .
Solusi lain yang disebutkan adalah dengan menggunakan skrip buatan sendiri (bergantung platform), yang benar-benar bertentangan dengan tujuan penulisan buruh pelabuhan yang dinyatakan sendiri, lihat komentar saya di atas , atau cukup beralih ke alat lain, yaitu membuang sempurna Anda toolchain yang berfungsi dengan baik hanya untuk mendapatkan fitur kecil ini dalam kenyamanan yang dapat dengan mudah diimplementasikan di toolchain Anda saat ini (docker-compose).

Satu-satunya argumen nyata yang diajukan terhadap implementasi paling dasar dari opsi 2 - yaitu memiliki _some way_ untuk memberi tahu docker-compose agar tidak memulai layanan tertentu secara default, dan tidak lebih, tidak ada konsep baru atau apa pun - adalah bahwa ini bisa be_somehow_ disalahgunakan oleh _some_ users.
Tetapi argumen ini cukup lemah dibandingkan dengan permintaan untuk itu dan kasus penggunaan yang sah yang diangkat di sini ...

@ shin-

tetapi juga karena kami [3] tidak memiliki waktu atau sumber daya untuk menerapkan atau mempertahankan apa yang dibutuhkan fitur ini agar benar-benar berguna bagi orang-orang.
[3] Dan pada poin ini yang saya maksud adalah "Saya", karena saya adalah satu-satunya pengelola yang secara aktif mengerjakan docker-compose saat ini.

Di satu sisi menyoroti bahwa hanya ada satu pengelola aktif sementara di sisi lain hanya mengabaikan permintaan tarik dan oleh karena itu menyia-nyiakan kesempatan untuk melibatkan pengembang lain dalam proyek bukanlah sesuatu yang dapat saya pahami.
Perubahan kode yang diberikan di # 3047 sudah _do_ mengimplementasikan fitur yang akan _sangat berguna untuk [banyak] orang_ - mungkin bukan _semua_ orang dengan _semua_ kasus penggunaan _mereka, tetapi sebagian besar orang di sini.

Semua persyaratan tambahan - harus memperkenalkan konsep yang benar-benar baru, manajemen ketergantungan baru, hingga kompleksitas seperti cmake - cukup ikuti dari premis yang salah!

Saya menemukan masalah ini beberapa hari yang lalu karena saya mencari fitur seperti ini.

Karena sayangnya tidak diterapkan, dan dari apa yang dapat saya kumpulkan, alternatif yang didukung secara resmi adalah menggunakan beberapa file yaml.

Nah, saya menemukan ide menggunakan beberapa file yaml untuk layanan tidak dijalankan secara default sebagai alternatif yang buruk dibandingkan dengan menggunakan satu file yaml untuk semua layanan yang berisi satu pengaturan tambahan untuk setiap layanan yang tidak dijalankan secara default.

Jadi, ini +1 saya.