Moby: Tambahkan dukungan untuk fitur `extends` di Compose v3 / docker stack deploy

Saya telah menambahkan beberapa catatan https://github.com/docker/compose/issues/4315#issuecomment -280617251 kepada saya membawa kembali meluas seperti yang ada hingga docker compose file versi 2.1 bukan ide yang baik tetapi fitur utama saya miss adalah untuk dapat mendeklarasikan layanan abstrak (yang tidak boleh dijalankan tetapi dapat digunakan untuk mengelompokkan properti umum layanan untuk kenyamanan).

Setuju dengan komentar dari docker/compose#4315 bahwa cara extends bekerja agak sederhana.

Saya tidak akan merekomendasikan solusi, tetapi FWIW, untuk menunjukkan tingkat penyalahgunaan, berikut adalah konvensi yang menghiasi bagian atas file penulisan kami:

#
# Docker Compose configuration
#
# Due to lack of "expressivity" in Compose, we define our own couple of service
# "pseudo-types":
#
#   - image-only services (name: *-image)
#
#     The only goal of these is to build images. No other services build images.
#
#     These have entrypoint overridden to exit immediately.
#
#   - base services (name: *-base)
#
#     These contain common configuration and are intended to be extended.
#
#     Their command (not entrypoint, to keep the original one) is overridden to
#     exit immediately. Service must support a command to exit immediately.
#
#   - task services (name: *-task)
#
#     These are intended for running one-off commands.
#
#     Their default command is overridden to exit immediately. Service must
#     support a command to exit immediately.
#
#   - "real" services
#
#     These are actual services that stay up and running.
#
version: '2'
services:
  ...

Saya pikir ekstensi seperti di v2.1 adalah pilihan yang baik. Extends sebenarnya sederhana dan dapat dimengerti, ini juga merupakan praktik yang baik untuk setiap lingkungan untuk memiliki sedikit dan dapat dibaca transformasi antara dev, prod dan env.

Sebenarnya, saya punya

• file komposisi buruh pelabuhan umum yang menyajikan aturan dasar
• sebuah dev docker compose memperluasnya dan dengan fasilitas untuk developper
• komposisi buruh pelabuhan pementasan yang meluas juga dan dengan fasilitas untuk lingkungan ini
• sebuah komposisi buruh pelabuhan produksi juga memperluas umum dan dengan fasilitas untuk lingkungan ini, khususnya replikasi wadah, aturan tentang memulai ulang, dll ...

Ini berhasil, dan saya tidak mengerti mengapa kita harus mencari di tiket ini penulisan ulang yang lengkap, tetapi lebih pada penyimpanan fitur yang menarik. Perluasan adalah bagian yang baik dengan kasus penggunaan khusus yang tidak dapat diselesaikan dengan mudah oleh teknik lain. Saya senang dengan kemungkinan yang diperluas.

Memblokir kami dari meningkatkan ke format v3.x juga.

Kami menyimpan definisi wadah buruh pelabuhan kami dalam tata letak folder-per-instance, di mana setiap folder berisi docker-compose.yml yang mendefinisikan spesifik env untuk instance container yang ada. Untuk memfaktorkan hal-hal umum (KERING) kami menggunakan definisi layanan dasar di folder induk dan menggunakan extend .

Jadi, ketika saya perlu mengelola instance container tertentu, saya hanya perlu cd ke folder yang tepat dan kemudian dapat langsung menjalankan perintah docker-compose tanpa konfigurasi lebih lanjut (tidak diperlukan flag -f yang anggota tim perlu mencari atau tahu, hanya berfungsi seperti yang diharapkan di luar kotak).

Saya diblokir dari menggunakan file penulisan versi 3.

Saya menggunakan services.yml untuk menentukan tata letak dasar layanan saya dan kemudian memperluasnya dengan dev.services.yml untuk lingkungan pengembangan saya (kebanyakan menambahkan volume) tetapi saya suka kegunaan ulang (KERING) dari perluasan ketika itu ditambahkan. Ini bukan pemecah kesepakatan tetapi itu akan mencegah saya pindah ke versi 3 kecuali ada fitur yang harus dimiliki.

Saya tidak menentang peningkatan solusi 'memperluas' v2.1 dengan sesuatu yang lebih tepat. Sesuatu seperti layanan abstrak bisa lebih aman digunakan dan lebih kuat.

Misalnya (karena abstrak) saya dapat membayangkan mendukung volume abstrak/mountpoints/jaringan, di mana layanan dasar abstrak mendefinisikan titik pemasangan lokal atau jaringan yang diperlukan untuk suatu layanan, tanpa mendefinisikan bagian Host - artinya layanan turunan kemudian dapat mendefinisikan/ memetakan bagian Host dari mount/volume dan jaringan ke apa yang sesuai di lingkungan Host/stage-nya.

Itu adalah contoh dari sesuatu yang tidak bisa kita lakukan sekarang dengan 'memperluas' sejauh yang saya tahu, dan akan membuka beberapa kemungkinan menarik.

Mengambil fitur ekstensi tidak membantu sama sekali. Kami memiliki banyak layanan web yang dimulai dengan volume yang sama yang dipetakan, variabel lingkungan, dan label yang ditetapkan. Mereka juga memiliki kebijakan pemeriksaan kesehatan yang sama. Dan Belum lagi port. Menggabungkan file penulisan menggunakan beberapa opsi -f itu membosankan dan rawan kesalahan jika Anda berurusan dengan banyak proyek di host yang sama.

@shin- apakah ini akan dibawa kembali pada skema 3.2?

Saya sangat, sangat ingin mengembalikan extends ke dalam format file. Saya telah menggunakannya untuk lebih menyempurnakan layanan abstrak untuk sejumlah proyek. Saya mengerti bahwa beberapa opsi -f hampir sesuai dengan tagihan, tetapi tidak selalu berhasil. Misalnya, saya agak sering mengubah nama layanan abstrak menjadi sesuatu yang lebih bermakna dalam konteks proyek yang sedang dikerjakan. Ini adalah sesuatu yang menimpa yang terjadi dengan beberapa opsi -f tidak mendukung.

Saya tidak keberatan kehilangan extends , selama mereka adalah cara lain untuk "membuat instance" layanan abstrak dalam file.

Saya memiliki pengaturan dengan file layanan umum dan banyak layanan yang memperluasnya, mengubah sebagian besar volume, jadi saya akan mengatakan saya mengandalkan fitur extends dan tidak melihat cara lain yang baik untuk menggambarkan pengaturan saya.

--frustrated

+1
Saya dapat melihat logika di balik rekomendasi untuk meratakan file yang dibuat oleh buruh pelabuhan, tetapi saya tidak suka gagasan menduplikasi kode yang mendefinisikan topologi layanan pengembangan kami di beberapa proyek. Kami akan menggunakan solusi -f untuk saat ini, dengan skrip shell sehingga pengembang tidak perlu mengingat layanan mana yang harus disertakan dalam kasus apa.

Saya berharap solusi yang memuaskan dapat ditemukan di sini untuk memungkinkan pemfaktoran struktur penulisan yang lebih baik!

Di bagian atas daftar kasus penggunaan saya adalah untuk MENGERINGKAN tumpukan layanan terkelola konfigurasi saya. Saya pikir saya bisa memanfaatkan 'extends' jika v3. Saya tidak ingin kembali ke v2... dan saya tidak ingin memiliki kasus khusus di mana saya harus menggunakan proses -f untuk menyelesaikannya.

Hei, apakah ada yang mulai mengerjakan ini? Saya tidak dapat menemukan PR untuk dilacak. Ini akan menyederhanakan banyak hal untuk kami di sini juga (kasus penggunaan sangat mirip dengan beberapa yang dijelaskan di atas).

Karena versi 3 dibekukan dan saya memerlukan cara untuk membagikan konfigurasi umum, saya meretas solusi kecil, yang menurut saya dapat saya bagikan di sini (saya tidak yakin apakah ini tempat yang tepat tetapi jangan ragu untuk memberi tahu saya di mana lagi saya bisa bagikan info ini :))

Saya tidak akan menguraikannya di sini, karena ada readme di repo.
Selamat bersenang-senang, semuanya ️

Sunting:

maaf ini link nya :D

+1

+1

+1

Terima kasih untuk +1nya
Sementara itu, saya telah menemukan lagi docker noop image , yang lebih kecil dengan faktor 10^3 (karena noop sebenarnya sedang ditulis dalam perakitan).

Sayangnya, tidak ada Lisensi dalam repo itu. Saya sudah menulis pesan kepada pemilik di facebk tetapi dia belum menjawab. Mungkin dia akan menambahkan lisensi jika lebih banyak orang menanyakannya tentang hal itu :)

Sesuatu yang mungkin membantu beberapa kasus penggunaan yang diperluas (yang ada dalam satu file) adalah dukungan untuk jangkar YAML: https://learnxinyminutes.com/docs/yaml/

Tampaknya Skema JSON mungkin gagal validasi pada mereka service must be a mapping, not a NoneType. .

Hei, @grayside , jangkar yaml berfungsi, setidaknya untuk saya. Lihat komentar saya di atas untuk cara saya menggunakannya.

Ok tapi terlalu sedih untuk menggunakan beberapa layanan noop bukan?

Khusus untuk env vars, nilai seperti apa yang ditangani oleh env vars itu? Jika ini tentang rahasia, gunakan fitur rahasia swarm (atau solusi rahasia lainnya). Jika ini tentang pengaturan, kami setuju bahwa sebagian besar pengaturan waktu adalah khusus aplikasi/layanan, tidak dimaksudkan untuk dibagikan di antara layanan.

Jika Anda perlu berbagi pengaturan antar layanan, sebagian besar waktu adalah saat Anda meluncurkan gambar wadah yang sama tetapi untuk tujuan/tugas runtime yang berbeda (konsumen, produsen, pekerja http, ...).

Jika ini tentang pengaturan, kami setuju bahwa sebagian besar pengaturan waktu adalah khusus aplikasi/layanan, tidak dimaksudkan untuk dibagikan di antara layanan.

Saya cenderung tidak setuju. Dalam proyek yang sedang saya kerjakan, saya menggunakannya misalnya untuk volume:

# Volume paths
environment:
  - &volume_a        volume-a:/usr/share/my_project/volumes/volume-a
  - &volume_b        volume-b:/usr/share/my_project/volumes/volume-b
  - &volume_c        volume-c:/usr/share/my_project/volumes/volume-c
  - &volume_d        volume-d:/usr/share/my_project/volumes/volume-d

Sekarang saya dapat menentukan volume ini seperti itu:

volumes:
  - volume-a:
  - volume-b:
  - volume-c:
  - volume-d:

services:
  some-service:
    image: some-image
    volumes:
      - *volume_a
      - *volume_b

  some-other-service:
    image: some-other-image
    volumes:
      - *volume_b
      - *volume_c

  some-third-service:
    image: yet-another-image
    volumes:
      - *volume_a
      - *volume_b
      - *volume_c
      - *volume_d

Ini membuatnya lebih mudah untuk menavigasi volume yang berbeda tanpa harus memikirkan wadah mana yang Anda gunakan. Imho, ini adalah salah satu cara untuk membuat pengaturan komposisi buruh pelabuhan Anda lebih konsisten dan lebih mudah digunakan dan dipelihara.

Ok ya saya mengerti @JanNash tetapi dalam contoh Anda di bawah ini, Anda tidak memiliki layanan noop kan?

Tetapi jangkar tidak cukup untuk banyak kasus.

Kasus saya melibatkan mendukung beberapa lingkungan untuk proyek yang sama. Anda dapat melihat perancah untuk proyek kami di sini .

Saat Anda mengembangkan, Anda menggunakan devel.yaml , tetapi dalam produksi Anda menggunakan prod.yaml . Ada juga test.yaml . Semuanya mewarisi dari common.yaml dan mendapatkan beberapa variabel umum dari file .env .

Masing-masing memiliki kekhasan tersendiri:

• lingkungan devel bertujuan untuk kecepatan pengembangan, sehingga menggunakan argumen build yang menghasilkan build lebih cepat, memasang volume dengan kode aplikasi dari komputer pengembang, dan menambahkan beberapa layanan dummy yang mengisolasi aplikasi dari dunia luar.
• prod bertujuan untuk stabilitas, jadi ia mengunduh dan mengkompilasi semua kode, dan menggabungkannya dalam gambar itu sendiri alih-alih menggunakan volume. Build lebih lambat, tetapi lebih aman.
• test bertujuan persis seperti prod, tetapi dengan isolasi dari layanan eksternal, untuk menghindari polusi dunia luar.

Pemisahan sederhana ini memungkinkan untuk memiliki saluran DevOps yang sangat gesit dan fleksibel, di mana setiap orang menggunakan kode yang sama di antara tahapan yang berbeda, hanya dengan sedikit penyesuaian tergantung pada lingkungan yang digunakan.

Saya mencoba untuk pindah ke format file penulisan v3, tetapi tidak hanya extends tidak didukung, tetapi juga .env , jadi sekarang ini akan menjadi mimpi buruk pemeliharaan (lebih karena kurangnya .env , jujur ​​saja). Saat memutuskan antara Swarm dan DRY, kami memilih DRY untuk saat ini, tetapi suatu hari nanti kami akan membutuhkan Swarm dan saya harap hari itu kedua fitur tersebut didukung lagi... ️

... atau setidaknya kami memiliki cara untuk menghasilkan format DRY-less yang valid dari solusi DRY-ful. Saya pikir docker-compose bundle adalah untuk itu, tetapi tampaknya sudah ditakdirkan untuk ditinggalkan sekarang ...

... atau kami memiliki alat berbeda yang membuat segalanya (saya juga mengawasi wadah yang memungkinkan ). Tapi tentunya ini bukan "perbaikan".

Tautan di https://github.com/moby/moby/issues/31101#issuecomment -301212524 menyertakan README dengan contoh kerja jangkar YAML. Melihatnya dan mencobanya lagi hari ini, itu berfungsi dengan baik. Tidak yakin apa yang saya lakukan berbeda.

@JanNash 👍

@Yajo Saya mendengar Anda dan seperti yang dikatakan, ini adalah solusi dan akan lebih baik dengan urutan besarnya jika ada solusi KERING bawaan yang baik yang disediakan oleh docker/moby/docker-compose (apa pun referensi yang benar) . Semoga semua segera hadir karena selain itu saya cukup senang dengan docker compose 👍

~ Demi kehilangan dukungan .env, saya juga meretas solusi (proyek saya belum diproduksi, jadi pembicaraan saya agak murah, saya tahu :)). Untuk mendukung set env vars yang berbeda (misalnya dependensi dan versi gambar/tag) di lingkungan yang berbeda (untuk saya saat ini, yaitu pengembangan lokal dan server dev kecil), saya menggunakan dua file, local.env dan development.env dan alih-alih menjalankan perintah saya hanya dengan docker-compose <command> , saya memasukkan file .env masing-masing ke dalam shell saya sebelumnya, atau saya menjalankannya seperti ini: (. local.env && docker-compose <command>) . Masih hack, tapi untuk saat ini, saya cukup senang dengan ini.~

Selamat bersenang-senang, kalian semua

Bahkan mungkin dua kali lipat :D

@JanNash tunggu! apakah .env tidak didukung lagi di 3 ?

Saya sebenarnya tidak tahu, saya baru saja membaca di komentar bahwa itu bukan.
Saya telah menggunakan prosedur local.env dan development.env terutama karena saya tidak tahu tentang autoenv ketika saya menerapkannya :D
Maaf untuk kemungkinan kebingungan.

Ah, @Yajo menyebutkan dukungan komentar ini .
Bisakah Anda menguraikan, @Yajo?

Ah maaf, salahku. Bukannya tidak berfungsi, hanya saja Anda harus menentukannya dengan env_file: .env , alih-alih dideteksi secara otomatis seperti sebelumnya. Mari kembali ke masalah awal.

Apakah diskusi untuk menjatuhkan extends mana saja? Saya ingin membacanya sebelum memberikan kasus penggunaan kami karena saya pikir itu dipahami dengan baik bahwa itu adalah fitur yang cukup sering digunakan.

Hai, saya punya satu pertanyaan - kapan? Kapan dukungan "memperpanjang" akan kembali di v3?

@JanNash Anda bisa menjadi jauh lebih kecil dari itu. Saya baru saja mengajukan masalah di github terhadap repo Anda, saya mendapat noop hingga 1200 byte dari 750k di mesin saya.

Saya melihat bahwa saya tidak dapat menggunakan perpanjangan saat ini di swarm.
adakah ide bagaimana meluncurkan layanan yang sama dengan port publikasi yang sama, dan dengan satu wadah pada layanan yang memiliki 1 variabel lingkungan tambahan?

+1 untuk memperluas dukungan dalam swarm stack deploy

Hai,
Kami menjalankan aplikasi microservices yang tersebar di beberapa repositori git (masing-masing memiliki file docker-compose).
Penyebaran dipimpin oleh satu file komposisi buruh pelabuhan "root" yang memperluas setiap layanan: bagi kami fitur extends ini benar-benar diperlukan untuk penyebaran tumpukan.
Begitu juga +1 untuk memperluas dukungan dalam swarm stack deploy
Terima kasih.

Anda dapat menggunakan warisan sederhana YAML (lihat &default , <<: *default ) sebagai solusi sementara:

version: '3'
services:
  worker: &default
    build: .
    command: bundle exec rake jobs:work
    env_file:
      - .env
    volumes:
      - .:/app
    depends_on:
      - db
      - redis
    links:
      - db:postgres
  web:
    <<: *default
    command: bundle exec puma -C config/puma.rb -p 3000
    ports:
      - "3000:3000"
  spring:
    <<: *default
    command: bundle exec spring server

Tentu saja, fitur extends lebih baik

Bagaimana bila Anda memperpanjang file yang berbeda?

Yaml tidak memiliki fitur perluasan file :(

Apakah ada update fitur ini dari kontributor Docker? Apakah ini direncanakan untuk diperkenalkan kembali? Jika tidak, apakah ada rencana untuk hal serupa? Jika tidak, mengapa tidak..?

@quolpr , saya khawatir kode "YAML simple inheritance" Anda tidak menggantikan extends dalam banyak kasus karena "prototipe" (yaitu &default ) akan selalu ditafsirkan oleh Docker Compose sebagai layanan yang disebut worker . Layanan mana yang a) perlu didefinisikan dengan baik, b) mungkin tidak diinginkan.

Pokoknya, pasti fitur yang menarik.

@laugimethods Anda juga dapat menggunakan referensi YAML:

version: '3'
services:
  spring:
    build: ./app
    command: /bin/sh -c "bundle exec spring server"
    volumes: &default_volumes
      - ./app:/app:delegated
      - bundle:/bundle:nocopy
  worker:
    build: ./app
    command: bundle exec sidekiq -v -C config/sidekiq.yml
    volumes: *default_volumes

(perhatikan &default_volumes dan *default_volumes )

Tapi saya benar-benar tidak mengerti mengapa fitur extends dihapus

FYI, untuk mengganti fitur "extends" yang hilang, saya sekarang menggunakan komposisi/penggabungan file .yaml :
https://github.com/Logimethods/smart-meter/blob/master/README.md#docker -compose

ekstensi berfungsi, sederhana dan matang, saya pikir jika seseorang melihat ekstensi sebagai anti-pola maka jangan gunakan itu, tapi tolong jangan potong

Bolehkah saya meminta penjelasan yang jelas tentang pendekatan yang dimaksud tanpa menggunakan extends ? Saya menggunakannya secara ekstensif, terutama ketika mewarisi dari file yang terdapat dalam submodul Git, memungkinkan definisi dari meta-proyek penanganan kabel jaringan lintas aplikasi, dll. Meskipun saya sangat sadar saya dapat menentukan beberapa file docker-compose.yml dan minta mereka diganti, apakah ini berarti saya perlu menentukan interkoneksi pada baris perintah, daripada dapat memeriksanya ke dalam kontrol sumber menggunakan extends ? Atau apakah saya melewatkan beberapa fitur baru di suatu tempat di v3?

Saya banyak menggunakan extends dalam beberapa proyek untuk mewarisi seperangkat atribut layanan umum untuk lingkungan yang berbeda dan host yang berbeda (baca: Saya menggunakan extends untuk mewarisi dari file yang berbeda).

Setelah membaca dalam keadaan pingsan penghapusan kata kunci extends dan mencoba mencari pengganti yang tidak memerlukan daisy chaining -f docker compose files Saya sangat ingin tahu apa alasan untuk menghapus extends .

Saya memahami masalah dengan links dan volume-from tetapi hanya menahan diri untuk menggunakannya dalam file yml dasar tampaknya merupakan hal terbaik untuk dilakukan.

Tidak mungkin melepas roda mobil hanya karena _mungkin_ terbiasa menjungkirbalikkan mobil... kan?

PS: noop dan jangkar terlihat menarik tetapi menambah kerumitan yang tidak perlu pada proyek paling sederhana ...

Sebagai contoh yang sangat, sangat sederhana:

common/common.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  ports:
    - "8080:8080"

prod/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  image: the-prod-image:latest-release
  ports:
    - "80:80"
    - "80:443"
  environment:
    NEW_RELIC_KEY:

Bagaimana Anda menjaga prinsip KERING tanpa extends ?

Saat ini saya tidak melihat alasan untuk memutakhirkan dari versi 2.1 karena ini.

@teodorescuserban ,

daisy chaining -f docker menulis file

Apa masalahnya dengan itu? Anda dapat membuat skrip Anda sendiri dengan alias pendek untuk memanggil docker-compose.

Gunakan struktur berikut:

umum/umum.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    ports:
      - "8080:8080"

prod/docker-compose.yml

services:
  web:
    image: the-prod-image:latest-release
    ports:
      - "80:80"
      - "80:443"
    environment:
      NEW_RELIC_KEY:

perintah

docker-compose -f common/common.yml -f dev/docker-compose.yml -p myproject up --build

docker-compose -f common/common.yml -f prod/docker-compose.yml -p myproject up --build

Saya tidak tahu fitur itu. Meskipun itu membuat CLI Anda , itu bisa berfungsi.

Saya pikir jika itu akan menjadi pengganti resmi untuk extends , maka harus ada cara untuk membuatnya lebih mudah.

Contohnya:

docker-compose.yml

version: "3"  # or whatever
extend:
  - ./common/common.yml
  - ./dev/docker-compose.yml
services: # Not required now
  # etc.

Dengan cara ini Anda dapat mengarahkan ke satu file docker-compose.yml yang melakukan semua yang Anda butuhkan.

Alternatif yang berguna adalah mendukung beberapa file penulisan di COMPOSE_FILE env var.

@Yajo

Alternatif yang berguna adalah mendukung beberapa file penulisan di COMPOSE_FILE env var.

Dari https://docs.docker.com/compose/reference/envvars/#compose_file :

Variabel ini mendukung beberapa file Compose yang dipisahkan oleh pemisah jalur (di Linux dan macOS pemisah jalur adalah : , pada Windows ; ). Misalnya: COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml . Pemisah jalur juga dapat dikustomisasi menggunakan COMPOSE_PATH_SEPARATOR .

@ dermeister0 Anda juga dapat menggabungkan file-file itu secara permanen dengan alat-alat seperti https://github.com/ImmobilienScout24/yamlreader :

> yamlreader common/common.yml prod/docker-compose.yml > docker-compose-prod.yml
> docker-compose -f docker-compose-prod.yml -p myproject up --build

> cat docker-compose-prod.yml
services:
    web:
        build: .
        environment:
            DOMAIN: null
            NEW_RELIC_KEY: null
            PREFIX: null
        image: the-prod-image:latest-release
        ports:
        - 80:80
        - 80:443

@ dermeister0 terima kasih atas saran Anda sayangnya ini adalah jalan keluar yang kikuk. Menggunakan extends menghapus kebutuhan untuk benar-benar tahu bagaimana tepatnya Anda perlu daisy chain itu. Meskipun saya bisa hidup dengan melakukan itu untuk diri saya sendiri, saya tidak pernah bisa menerapkan solusi ini untuk para pengembang tersayang.

Namun, saya tidak menyadari bahwa variabel env COMPOSE_FILE dapat berisi banyak nilai. Terima kasih @gsong ! Itu luar biasa dan dapat menggunakannya (saya mendefinisikannya di file .env ). Ada satu masalah tunggal di sini: di file dasar/umum saya mungkin juga memiliki beberapa layanan yang tidak saya perlukan.

Ambil contoh file umum datar yang mendefinisikan basis data dan wadah web. Pada pementasan Anda ingin mereka semua mengelompok bersama tetapi pada prod Anda ingin host terpisah untuk db dan untuk web.

Juga, docker-compose.override.yml dimuat secara default.

https://docs.docker.com/compose/extends/#understanding -multiple-compose-files

Saya menggunakan pendekatan ini dengan versi 3.3:

• letakkan opsi dan layanan konfigurasi umum di docker-compose.yml ;
• gunakan docker-compose.override.yml untuk konfigurasi dan layanan pengembangan tertentu (seperti xdebug misalnya);
• gunakan docker-compose.staging.yml untuk opsi konfigurasi pementasan tertentu.

Catatan: Saya tidak menjalankan Docker dalam produksi.

Dengan menggunakan pendekatan ini saya dapat dengan mudah membangun secara lokal menggunakan docker-compose build dan ketika saya menerapkan pada pementasan saya menggunakan:

docker-compose -f docker-compose.staging.yml -f docker-compose.yml build

Saya menggunakan Apache, dan saya tidak memiliki file host virtual terpisah untuk pengembangan dan pementasan. Saya telah menghabiskan cukup banyak untuk menghindari file yang berbeda. Pada akhirnya saya telah melihat satu-satunya pendekatan yang valid adalah menggunakan <IfDefine> dan variabel lingkungan (yang saya atur di bagian lingkungan dari file yml), untuk memasukkan konfigurasi ssl misalnya. Dan saya menggunakan TLD dan awalan domain, jadi saya dapat memiliki sesuatu seperti www.example.local http://www.example.local/ :8080 dan www.staging.example.com http://www.staging.example.com / . Secara lokal, situs web berjalan di bawah http dan pada staging di https. Dengan pendekatan ini saya tidak perlu mempertahankan versi file yang berbeda. Saya pikir hal yang sama dapat dilakukan dalam produksi, tetapi seperti yang saya katakan, saya lebih suka menghindari Docker dalam produksi, atm.

Semua jalur adalah kerabat, sehingga wadah akan berfungsi di lingkungan apa pun.

2 sen saya

-Filippo

Dalam kasus saya, sebelumnya saya menggunakan sesuatu seperti ini:

• umum.yml
• devel.yml -> memperluas common.yml
• prod.yml -> memperluas common.yml
• docker-compose.yml -> lokal, git-diabaikan, symlink ke lingkungan yang diinginkan (devel atau prod).

Terima kasih kepada https://github.com/moby/moby/issues/31101#issuecomment -329482917 dan https://github.com/moby/moby/issues/31101#issuecomment -329512231, yang tidak saya ketahui, sekarang saya bisa pindah ke v3 dengan menggunakan skema yang berbeda:

• docker-compose.yml -> apa yang sebelumnya adalah common.yml
• devel.yml -> mengganti docker-compose.yml
• prod.yml -> menimpa docker-compose.yml
• docker-compose.override.yml -> lokal, git-diabaikan, symlink ke lingkungan yang diinginkan (devel atau prod).

Saya juga dapat melakukan peretasan yang diperlukan dengan menggunakan variabel env, jadi dalam kasus saya masalahnya sudah diperbaiki. Terima kasih! (Maaf, saya seharusnya membaca dokumen baru dengan benar sebelum mengeluh).

PS: Tetap saja, extends akan menjadi hal yang baik untuk kembali, tetapi setidaknya kami memiliki alternatif yang cukup adil. 😊

@shin- Pertama saya sangat kecewa melihat fitur extends hilang di 3.0 , tetapi jangkar YAML (contoh: https://github.com/JanNash/docker-noop) akan menjadi penggantian yang lebih dari cukup.

Satu-satunya hal adalah, seperti pada contoh di atas, Anda perlu meletakkan jangkar Anda di beberapa bagian yang valid dari file docker-compose.yml .

Bisakah kita mendapatkan properti templates (tingkat atas) atau kunci tersembunyi seperti di GitLab agar lebih fleksibel dalam menentukan jangkar?

@schmunk42 lihat https://github.com/docker/cli/pull/452

Masalah dengan mengandalkan docker-compose.override.yml adalah bahwa itu mengandaikan Anda hanya memiliki satu jenis penggantian yang perlu Anda sertakan, dan satu lapisan penggantian.

Dalam kasus saya, saya ingin memiliki perilaku tertentu yang umum untuk semua pengembangan lokal, tetapi mungkin perlu sedikit berbeda jika pengembang menjalankan Windows, OSX, atau Linux. Agar ini dapat dikelola dalam konteks v3 komposisi buruh pelabuhan, saya memiliki pengguna Linux yang beroperasi pada perilaku yang sama dengan lingkungan pementasan, yang berfungsi tetapi berarti mereka sedikit keluar dari langkah dengan pengembang lain.

Saya menghindari penggunaan -f untuk pengembangan lokal karena saya menemukan itu sangat rentan terhadap kesalahan manusia, dan mengandalkannya sebagai sakelar untuk terlalu banyak hal menyebabkan masalah. Memilih satu file tampaknya masuk akal, memilih beberapa adalah sesuatu yang saya hindari dengan hati-hati.

FYI, saya berpikir bahwa setelah hack dengan x- disebutkan di atas, dan juga daisy chaining buruh pelabuhan-compose file menggunakan COMPOSE_FILE variabel dalam .env file proyek, menambahkan docker- yang compose.override.yml harus menyelesaikan setiap kasus penggunaan yang saya temui sejauh ini.

Jangkar yml juga merupakan hal bagus yang ingin saya gunakan dalam waktu dekat.

Tidak terlalu senang dengan keindahan hack x- tapi saya bisa hidup dengan itu.

Terima kasih atas masukan Anda!

Sepertinya penghapusan extends menyebabkan banyak mulas dan memblokir pindah ke v3 atau beralih ke peretasan. Saya suka kemampuan untuk mendefinisikan layanan "templat" (atau abstrak) yang dapat membawa beberapa hal umum (mis. kebijakan pembaruan)

Saya sedang mengerjakan utilitas filter golang sederhana yang dapat melakukan pra-proses file penulisan buruh pelabuhan dengan extends dan mengeluarkan file v3 bersih dengan ekstensi diselesaikan:
menyelesaikan-menulis docker stack deploy -c docker-compose.yaml
(atau docker-compose up)

Apakah ini akan berfungsi untuk setidaknya beberapa kasus penggunaan Anda/mengapa gotcha?

@pnickolov Itu akan sangat indah bagi saya.

Saya telah mencari wadah yang memungkinkan (saya menggunakan ansible secara pribadi, tetapi belum bekerja), yang sepertinya akan melakukan semua yang saya butuhkan, tetapi skrip seperti milik Anda akan lebih disukai (lebih sedikit churn)

Selama itu dapat memproses kunci extends: secara rekursif, saya akan senang!

Oke, sepertinya kami menemukan alternatif untuk extends ... 👍

Apa yang mengganggu adalah kenyataan bahwa Manajemen Proyek Moby tampaknya tidak mempertimbangkan untuk menjaga kompatibilitas sebagai elemen kunci. Kompatibilitas ke depan sangat penting untuk adopsi yang lebih luas, terutama untuk aplikasi besar yang digunakan dalam produksi. Bagaimana kita bisa mendorong Docker Swarm / Docker EE ketika tidak ada jaminan bahwa fitur inti seperti extends akan tetap ada? 👎
Reputasi yang baik sulit untuk menang dan mudah untuk kehilangan ...

Secara pribadi, saya lebih suka mengandalkan fitur YAML asli untuk menyelesaikan tugas yang ditangani oleh extends dalam sintaks v2 , daripada skrip khusus atau solusi yang lebih besar seperti yang dimungkinkan. Saya mengalami masalah serupa sebelumnya dan mulai menulis konverter saya sendiri sebelum ada solusi seperti menggunakan beberapa file .yml dll. (https://github.com/schmunk42/yii2-yaml-converter-command) - tetapi tidak solusi yang layak.

Bagi saya, tidak masalah untuk menghentikan fitur, jika ini dilakukan bersama dengan kebijakan pembuatan versi; Anda tidak dapat membawa barang-barang lama selamanya, bahkan jika ini berarti ada pekerjaan di pihak kita.

@schmunk42 Menghentikan fitur tidak masalah, tetapi hanya jika:

• fitur yang dihapus tidak lagi benar-benar digunakan atau merupakan penghalang nyata untuk evolusi
• diumumkan sebelumnya
• jalur migrasi disediakan segera

Sayangnya, tidak satu pun dari persyaratan itu (dalam buku saya) yang berlaku untuk penghentian extends ...

@laugimethods Apa alasan Anda perlu menggunakan v3 ?

@schmunk42 Karena Swarm:

Versi 3.x, versi terbaru dan yang direkomendasikan, dirancang agar kompatibel silang antara Compose dan mode gerombolan Docker Engine. Ini ditentukan dengan versi: '3' atau versi: '3.1', dll., entri di root YAML.

Perintah penyebaran tumpukan buruh pelabuhan mendukung semua file Tulis versi "3.0" atau lebih tinggi

Btw, komentar saya tidak hanya terkait dengan extends , tetapi juga penolakan (menyakitkan) yang mungkin terjadi di masa mendatang...

Ya, kami menghadapi masalah yang sama karena mode swarm.

Saya bertanya pada diri sendiri sejak awal, mengapa CLI buruh pelabuhan sekarang dapat menggunakan input --composer-file . Tetapi dari pembelajaran kami dengan docker/swarm sepertinya hal yang cukup rumit untuk menjalankan tumpukan pada kawanan (pengelolaan sendiri) dan ada beberapa alasan bagus mengapa ini dipindahkan ke mesin.

Sebagai catatan beberapa temuan saya di sini ... transisi dari v2 ke v3.4 jauh dari mudah.

Beberapa masalah saya:

• ada opsi lain yang tidak didukung seperti volumes_from , agak mudah untuk dielakkan, karena kami tetap ingin menghapusnya
• .env file (seperti dengan docker-compose ) tidak berpengaruh dengan Docker CLI
• menentukan beberapa file penulisan ( docker stack deploy -c docker-compose.yml -c docker-compose.override.yml doro ) tampaknya tidak berfungsi dengan benar, tidak ada kesalahan, tetapi menurut saya mereka juga tidak digabungkan dengan benar - tetapi juga tidak ada perintah seperti docker-compose config untuk memeriksanya
• tidak ada biner "mudah dipasang" (pra-rilis) untuk docker-compose yang mendukung sintaks v3.4 ; seperti tepi Docker
• jaringan eksternal perlu dibuat dengan --scope swarm

CC: @kode tangan

Menggunakan build terbaru

• buruh pelabuhan 17.09.0-ce
• docker-compose 1.17.0dev

Saya sekarang menggunakan pipa konfigurasi ini untuk menggantikan penggunaan _extend_ dan _noop_ saya
Menjaga hal-hal sedikit KERING
Semoga ini bisa membantu seseorang

base.yml (definisi bersama, ini adalah dokumen yaml yang valid, jadi dapat digabungkan menggunakan _docker-compose config_)

version: '3.4'
networks:
  net_back:
    external: true

base-inject.yml (definisi jangkar bersama, sayangnya tidak dapat ditambahkan ke base.yml karena jangkar tidak dapat direferensikan ke file yaml yang berbeda, sebaliknya ini disuntikkan sebagai teks ke foo.yml , bukan cara yang ideal untuk melakukan ini)

x-logging: &logging
  driver: json-file
  options:
    max-size: "50m"
    max-file: "2"

foo.yml (definisi tumpukan umum, referensi objek dari base.yml , jangkar dari base-inject.yml dan objek diganti di foo-dev.yml )

version: '3.4'
[[base-inject]]
services:
  foo:
    image: ${DOCKER_REGISTRY}/foo:${IMAGE_VERSION}
    volumes:
      - type: volume
        source: "volfoo"
        target: "/foo"
    networks:
     - net_back
    logging:
      <<: *logging

foo-dev.yml (per definisi tumpukan lingkungan)

version: '3.4'
services:
  foo:
    ports:
      - "8080:80"
volumes:
  volfoo:
    name: '{{index .Service.Labels "com.docker.stack.namespace"}}_volfoo_{{.Task.Slot}}'
    driver: local

Kemudian perintah penyebaran:

docker stack rm stack_foo && echo "waiting..." && sleep 3 &&
  cat foo.yml | sed -e '/base-inject/ {' -e 'r base-inject.yml' -e 'd' -e '}' > ./foo-temp1.yml &&
  export $(sed '/^#/d' ./dev.env | xargs) &&
  docker-compose -f base.yml -f ./foo-temp1.yml -f foo-dev.yml config > ./foo-temp2.yml
  docker stack deploy --with-registry-auth --prune --compose-file ./foo-temp2.yml stack_foo

1. Hapus tumpukan lama
2. Tunggu tumpukan yang dapat dilepas untuk disebarkan
3. Suntikkan jangkar ke dalam definisi umum, simpan ke file tmp
4. Baca + setel variabel file env dari file
5. Gunakan docker-compose untuk menggabungkan ketiga file menjadi satu
6. Menyebarkan file gabungan

Bagi Anda yang menginginkan extends dalam menulis 3+ file, saya baru saja menggunakan alat bernama baclin . baclin linearisasi direktif tersebut, secara rekursif mengganti semua direktif extends dengan kontennya. Ini adalah perangkat lunak alfa, kodenya adalah bagian dari mesin saya karena saya sedang menulis kode untuk mendukung mode Swarm dan penyebaran tumpukan. Binari platform dari versi awal baclin tersedia di sini . Silakan laporkan komentar atau masalah apa pun di sini .

Ini benar-benar membingungkan!
Membaca dokumen untuk rilis buruh pelabuhan terbaru ( v17.09 ) dan juga dokumen rilis v17.06 fitur ini harus tersedia.

$ head -n1 docker-compose.yml
version: '3'

Tapi compose up menghasilkan

ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.admin_application: 'extends'

saat menggunakan kata kunci extends .
Juga, saya tidak dapat menemukan apa pun tentang penghapusan extends di compose changelog .

Sekarang yang mana?!
Info penting seperti ini seharusnya tidak sulit ditemukan atau disembunyikan di dalam beberapa masalah github yang tidak jelas.

$ docker --version
Docker version 17.09.0-ce, build afdb6d4

$ docker-compose --version
docker-compose version 1.16.1, build 6d1ac21

@jottr , Lihat dokumen :

Kata kunci extends didukung dalam format file Compose sebelumnya hingga Compose file versi 2.1 (lihat perluasan di v1 dan perluasan di v2), tetapi tidak didukung di Compose versi 3.x.

Jadi jika Anda ingin menggunakan extends Anda harus tetap menggunakan version: '2.1' .

Salahku. Itu masih harus di bagian atas dokumen dengan tanda peringatan penghentian merah.

Salahku. Itu masih harus di bagian atas dokumen dengan tanda peringatan penghentian merah.

@jottr Cukup gunakan Github untuk membuat masalah terpisah untuk itu atau bahkan buat PR untuk itu. Baru saja membuat masalah di sini: https://github.com/docker/docker.github.io/issues/5340

Dalam kasus saya, saya memiliki docker-compose-override.yml sebagai berikut:
yaml version: "3.4" services: common: extra_hosts: - "host1:172.28.5.1" - "host2172.28.5.2" - "host3:172.28.5.3" networks: default: external: name: "common-network"
Dan saya memiliki beberapa file docker-compose.yml yang perlu berbagi jaringan dan extra_hosts. Bagaimana melakukan ini menggunakan fitur tanpa ekstensi?

yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" hostname: "mongo" volumes: - "/opt/docker/mongo/default.conf:/usr/local/etc/mongo/mongod.conf" - /opt/data/mongo:/data/db" ports: - "27017:27017" command: "mongod --config /usr/local/etc/mongo/mongod.conf" networks: default: ipv4_address: "172.28.5.4"
Akan lebih bagus jika docker-compose mendukung jangkar yaml dan referensi antara file yang berbeda. Mungkin, menerapkan jangkar dan referensi setelah menggabungkan file.
Sebagai contoh:
yaml version: "3.4" services: common: &common extra_hosts: ... networks: ...
yaml version: "3.4" services: mongo: <<: *common image: "mongo" container_name: "mongo" ...
Hasilnya harus:
yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" extra_hosts: // EXTRA HOSTS HERE networks: ...

@sandro-csimas ini dimungkinkan dengan: https://docs.docker.com/compose/compose-file/#extension -fields
@shin- bisakah tiket ini ditutup?

@rdxmb saya rasa tidak. Dari apa yang saya lihat, Anda tidak dapat memperluas dari file penulisan buruh pelabuhan lainnya

Apakah saya benar dalam berpikir bahwa ini adalah masalah untuk https://github.com/docker/compose/issues ?

Beberapa debugging:

# cat docker-compose.yml 
version: "3.4"
services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

Ini bekerja dengan
docker stack deploy -c docker-compose.yml test

Saat menggunakan komposisi buruh pelabuhan:

# docker-compose up 
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./docker-compose.yml", line 4, column 10

Mengubah file yml menjadi:

version: "3.4"

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR

juga bekerja dengan docker-compose.

Jadi saya pikir ini juga harus bekerja dengan banyak file, yang tidak demikian:

# docker-compose -f compose-services.yml -f compose-default.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10
t# docker-compose -f compose-default.yml -f compose-services.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10

# cat compose-services.yml 
version: "3.4"

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

# cat compose-default.yml 
x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

Namun, tentu saja, penggabungan ini dimungkinkan dengan penggunaan sederhana cat :

# cat compose-default.yml compose-services.yml > docker-compose.yml && docker-compose up -d
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use `docker stack deploy`.

Creating network "test_default" with the default driver
Creating test_foo-bar_1 ... 
Creating test_foo-not-bar_1 ... 
Creating test_foo-bar_1
Creating test_foo-bar_1 ... done

Berjalan di xenial dengan versi:

# docker --version
Docker version 17.11.0-ce, build 1caf76c
# docker-compose --version
docker-compose version 1.17.0, build ac53b73

@rdxmb , terima kasih!
Jadi saya harus menggabungkan file penulisan menggunakan perintah "cat" dan menjalankan file akhir.

Saya juga menggunakan docker-compose config untuk melakukan ini. Contoh untuk pengaturan khusus lingkungan:

Ini dijalankan oleh pipa CI: docker-compose -f docker-compose.yml -f docker-compose.override.prod.yml config > docker-compose.prod.yml dan kemudian saya menggunakan docker stack deploy -c .\docker-compose.prod.yml my-stack

Pilih ini, ekstensi ini sangat berguna untuk v3.

Banyak menggunakannya dengan v2, memang sangat berguna!
+1

Saya ingin melihat dukungan extends di v3. Ini akan sangat membantu KERING file docker-compose.yml .

Sudah hampir setahun sejak masalah ini dibawa dan sangat jelas bahwa banyak orang membutuhkan fitur ini. Namun saya belum membaca dev Docker yang menanggapi permintaan ini sama sekali, atau penjelasan mengapa itu tidak termasuk dalam docker-compose v3 sebelum rilis.

Keadaan perangkat lunak yang menyedihkan jika kami bahkan tidak dapat berkomunikasi atau memelihara fitur untuk pelanggan kami yang percaya pada teknologi baru.

Salah satu interpretasi yang mungkin (dan mungkin juga ringkasan utas saat ini) dari situasinya adalah seperti ini:

• Jangkar/referensi YAML ditambah bidang ekstensi 3.4 mencapai hampir sama.
• multi-file dapat dibuat untuk bekerja. Lihat cat dan pendekatan lanjutan di utas ini. Komentar pendekatan sederhana menunjukkan masalah penulisan buruh pelabuhan yang memuat banyak file menjelang akhir (adakah yang membuat masalah untuk itu?). Jika itu diperbaiki dalam komposisi buruh pelabuhan, Anda bahkan tidak memerlukan penggabungan file sama sekali. Jadi bagi saya orang yang menginginkan dukungan multi-file harus melanjutkan di docker/compose/issues seperti yang diusulkan @rdxmb .
• Membawa kembali extends dipertimbangkan (lihat acara proyek GitHub , transparansi yang bagus di sini dari tim Docker, terima kasih!) masih menulis permintaan tarik untuk extends kurasa.

Bagi saya itu adalah sudut pandang yang sangat bisa dimengerti.

@aCandidMind Setuju.

IMHO, meskipun pendekatan yang disebutkan oleh @aCandidMind berfungsi, mereka menambah kompleksitas pada mekanisme yang lebih sederhana dan lebih bersih yang disediakan oleh extends .
Mungkin ini saya, tetapi memindahkan konfigurasi ekstensi yang cukup rumit ke bidang ekstensi menjadi jauh lebih sulit untuk dibaca dan dipelihara.
Setelah membaca banyak komentar dan posting, masih belum jelas bagi saya mengapa ekstensi dijatuhkan dan apa keuntungan dari regresi dalam kemampuan ini.

Dimungkinkan dengan sedikit sihir bash saya memasang repo uji sehingga Anda dapat mencobanya sendiri.

Susun saja perintah stack deploy seperti ini:

docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config) <stackname>

@tylerbuchea - satu-satunya downside ke bash magic itu adalah Anda mungkin mendapatkan WARNING: Some services (<service-name(s)>) use the '<key>' key, which will be ignored. Compose does not support '<key>' configuration . Ini dapat menyebabkan beberapa kebingungan. Tapi hei, itu berhasil 👍

@dnmgns Anda benar! Terima kasih telah menunjukkan hal itu. Seperti yang dikatakan @joaocc tidak ada yang akan mengalahkan dukungan asli, tetapi solusi yang saya sebutkan di atas adalah yang terbaik yang dapat saya temukan mengingat tidak ada dependensi selain bash.

@tylerbuchea Salah satu cara kotor adalah dengan mengarahkan stderr ke /dev/null :)
docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config 2> /dev/null) <stackname>

Tidak ada rasa malu di dalamnya

Saya pikir dokumentasi harus lebih eksplisit tentang kebingungan ini sekitar extend .
Deskripsi extend mengarahkan pengguna ke dokumen cara meningkatkan versi, dan dokumen cara meningkatkan versi mengarah kembali ke deskripsi extend untuk informasi lebih lanjut. Ini tidak cukup membantu: sebagai pengguna saya mengharapkan bantuan bagaimana menangani seluruh masalah ini, opsi apa yang saya miliki dan apa yang harus saya pertimbangkan. Saya sangat yakin ada ide yang jelas di balik keputusan menghapus extend dari v3.

Lihat:
https://docs.docker.com/compose/extends/#extending -services
https://docs.docker.com/compose/compose-file/compose-versioning/#upgrade

Mengenai @tylerbuchea solusi berbasis bash one-liner yang hebat,
sayangnya itu tidak mendukung beberapa fitur tumpukan Docker lanjutan:

WARNING: Some services (web) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
WARNING: Some services (web) use the 'configs' key, which will be ignored. Compose does not support 'configs' configuration - use `docker stack deploy` to deploy to a swarm.

Bukan karena https://github.com/docker/cli/pull/569 go digabung, mulai dari 18.03, docker stack deploy akan mendukung penggabungan beberapa file penulisan menjadi satu. Itu tidak sepenuhnya menggantikan kunci extends dari format composefile v2 tetapi mudah-mudahan ini mencakup lebih banyak kasus penggunaan

Solusi saya sendiri adalah menggunakan yq (dapat digabungkan menjadi satu baris jika menggunakan Bash):

yq merge --overwrite docker-stack.yml docker-stack.preprod.yml > merged-docker-stack.yml
docker stack deploy -c merged-docker-stack.yml preprod

@Lucas-C mereka hanya memperingatkan bahwa output masih akan menyertakan kunci deploy dan config . Anda dapat memverifikasi ini jika Anda menjalankan docker-compose -f docker/prod.yml -f docker/dev.yml config

Ini untuk menulis file v3.4 dan lebih tinggi. Ini mendukung referensi lintas yaml (sebagian). Saya selesai dengan skrip zsh alias/Perl ini:

alias regen=$'perl -MFile::Slurp=read_file -MYAML=Load,Dump -MHash::Merge::Simple=merge -E \'
  local $YAML::QuoteNumericStrings = 1;
  $n=read_file("/data/docker-compose.yml");
  $s=Dump(merge(map{Load($n.read_file($_))}@ARGV));
  local $/ = undef;
  $s =~ s/\\bno\\b/"no"/g;
  say $s;
  \' $(find /data -mindepth 2 -maxdepth 4 -name docker-compose.yml) >! /data/x-docker-compose.yml'
regen
export COMPOSE_FILE=/data/x-docker-compose.yml

1. baca /data/docker-compose.yml dengan bagian umum.
2. temukan semua penulisan buruh pelabuhan secara rekursif (Misalnya ada sekitar 40 file container/docker-compose.yml yang berbeda dalam proyek ini)
3. tambahkan setiap docker-compose.yml dengan konten /data/docker-compose.yml
4. menggabungkan
5. simpan hasilnya ke /data/x-docker-compose.yml

Kelebihan : Perl adalah alat yang umum, semua modul Perl juga, generasinya cepat.
Cons : Saya benci peretasan tetapi tidak ada cara lain untuk KERING. Komposisi buruh pelabuhan akhir adalah sekitar 900 baris. Apakah Anda benar-benar ingin saya mendukungnya sebagai satu file dari awal? Sayang sekali jika buruh pelabuhan biner dibungkus dengan python docker-compose dibungkus dengan perl hack.

Bagaimana Anda bisa mengeluarkan fitur seperti ekstensi? Itu sepertinya fitur inti.

Menggunakan docker-compose config disalurkan ke opsi input standar docker stack deploy -c - telah memecahkan masalah bagi saya:

docker-compose -f docker-compose.yml \
               -f docker-compose.extended.yml \
               config \
| docker stack deploy -c - my-stack

Saya belum mencoba ini, tetapi saya juga baru menyadari ini di dokumentasi docker stack deploy :

Jika konfigurasi Anda dibagi antara beberapa file Compose, misalnya konfigurasi dasar dan penggantian khusus lingkungan, Anda dapat memberikan beberapa flag --compose-file .

Dengan ini sebagai contoh:

docker stack deploy --compose-file docker-compose.yml -f docker-compose.prod.yml vossibility

https://docs.docker.com/engine/reference/commandline/stack_deploy/#compose -file

Apakah alasan untuk menghapus extends didokumentasikan di suatu tempat? Tampaknya tidak dijelaskan dalam dokumen resmi, misalnya di sini: https://docs.docker.com/compose/extends/#extending -services
Jika pengguna dapat memahami alasannya, maka pengguna dapat mengembangkan ide yang lebih baik tentang bagaimana menanggapi penghapusan tersebut. Terima kasih.

@shaun-blake Saya akhirnya menggunakan beberapa file penulisan. Itu tampaknya menjadi pendekatan yang digunakan orang. Daripada warisan itu lebih seperti campuran. Saat membangun atau menjalankan, saya menyalin template yaml lingkungan yang benar ke docker-compose.override.yml.

Beberapa file penulisan buruh pelabuhan (misalnya: base.yml , local.yml , prod.yml ) tidak mengizinkan layanan menggunakan jangkar YAML dari file lain sehingga definisi layanan yang difaktorkan tidak dapat ditentukan di antara beberapa file yml .
Catatan, masalah ini adalah yang paling banyak dikomentari ke - https://github.com/moby/moby/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc dan ke - disukai .

Jika pengguna dapat memahami alasannya, maka pengguna dapat mengembangkan ide yang lebih baik tentang bagaimana menanggapi penghapusan tersebut. Terima kasih.

+1 pada dokumentasi tentang alasan untuk menghapus extends di tempat pertama...

Masih tidak ada _extends_ setelah hampir 1 setengah tahun kemudian. Cmon, devs, Anda tidak menghapus sth tanpa memberikan alternatif.

Mereka melakukannya, mereka menawarkan alternatif yang disebut komposisi. Silakan baca jawaban saya di utas.

-Filippo

Pada 30 Juli 2018, pukul 09:41, Xiaohui Liu [email protected] menulis:

Masih belum ada perpanjangan setelah hampir 1 setengah tahun kemudian. Cmon, devs, Anda tidak menghapus sth tanpa memberikan alternatif.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub https://github.com/moby/moby/issues/31101#issuecomment-408790200 , atau nonaktifkan utasnya https://github.com/notifications/unsubscribe-auth/AAS_0AOynjpfVnVo4ZqciMbmjBmkcTQ3MDs5JpZMjBmkcTQ3MDs

@dedalozzo , "di utas" == ?

Silakan lihat komentar saya di sini:

https://github.com/moby/moby/issues/31101#issuecomment -329527600 https://github.com/moby/moby/issues/31101#issuecomment-329527600

Pada dasarnya Anda harus menggunakan rantai file .yml untuk mengganti atau mengubah konfigurasi wadah Anda.

Silakan baca "Menentukan beberapa file Tulis"

Anda dapat menyediakan beberapa file konfigurasi -f. Saat Anda menyediakan beberapa file, Compose menggabungkannya menjadi satu konfigurasi. Compose membangun konfigurasi dalam urutan yang Anda berikan pada file. File berikutnya menimpa dan menambahkan ke pendahulunya.

https://docs.docker.com/compose/reference/overview/ https://docs.docker.com/compose/reference/overview/

Pendekatan ini menggunakan komposisi daripada pewarisan untuk mendapatkan, kurang lebih, hasil yang sama.

Pada 30 Juli 2018, pukul 15:23, Serban Teodorescu [email protected] menulis:

@dedalozzo https://github.com/dedalozzo , "di utas" == ?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/moby/moby/issues/31101#issuecomment-408880809 , atau matikan utasnya https://github.com/notifications/unsubscribe-auth/AAS_0FZO30NplqHRid_Id8VBOJW7nk5Iks5uLx .

Bukankah kita bisa mendapatkan perpanjangan yang sama kembali jika kita menggabungkan
bidang ekstensi yaml (tulis 2.1+/3.4+)
dengan mengizinkan bidang x- untuk mereferensikan file lain ?

Jadi kita bisa mengizinkan daftar root include untuk menentukan file yang akan dimuat.
mereka akan dimasukkan ke dalam x-include dan langsung dapat digunakan melalui jangkar & penggabungan YAML standar.

# /docker-compose.yml
version: '2.1'

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

# /proxy/docker-compose.yml
version: '2.1'
services:
  proxy:
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '2.1'
services:
  app:
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /proxy/docker-compose.yml
version: '3.9'
services:
  proxy:
    &proxy
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '3.9'
services:
  app:
    &app
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /docker-compose.yml
version: '3.9'
include:
  - /proxy/docker-compose.yml
  - /webservice/docker-compose.yml

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    restart: 'always'
    << : *proxy
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    restart: 'no'
    extends:
      file: web1/docker-compose.yml
      service: app
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

@@ /proxy/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   proxy:
+    &proxy
     build: ./
     volumes:
       - /certs:/certs:ro
 ```

 ```diff
 @@ /webservice/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   app:
+    &app
     build:
       context: ./folder
       args:
         LINUX_VERSION: 20.s
         LINUX_FLAVOR: dash
     environment:
       - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
       - bootstrap.memory_lock=true
     ulimits:
       memlock:
         soft: -1
         hard: -1
 ```

 ```diff
 @@ /docker-compose.yml @@
-version: '2.1'
+version: '3.9'
+include:
+  - /proxy/docker-compose.yml
+  - /webservice/docker-compose.yml

 volumes:
   nginx_file_sockets:
     external: false
     driver: local

 services:
   reverse_proxy:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'always'
     ports:
       - "80:80"
       - "443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   reverse_proxy_test:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'no'
     ports:
       - "8080:80"
       - "8443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'always'
     environment:
       ENVIRONMENT: 'production'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web_staging:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'no'
     environment:
       ENVIRONMENT: 'staging'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx
 ```
<hr>
Resulting in the final version, which should be already yaml parsable:

```yml
# /docker-compose.yml
version: '3.9'
#include:
#  - /proxy/docker-compose.yml
#  - /webservice/docker-compose.yml
x-include:
  /proxy/docker-compose.yml:
    version: '3.9'
    services:
      proxy:
        &proxy
        build: ./
        volumes:
          - /certs:/certs:ro
  /webservice/docker-compose.yml:
    version: '3.9'
    services:
      app:
        &app
        build:
          context: ./folder
          args:
            LINUX_VERSION: 20.s
            LINUX_FLAVOR: dash
        environment:
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
          - bootstrap.memory_lock=true
        ulimits:
          memlock:
            soft: -1
            hard: -1

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    << : *proxy
    restart: 'no'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    << : *app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

AFAIK itu adalah fitur YAML, yang dibangun ke dalam spesifikasi laguage itu sendiri, untuk menghindari pengulangan bagian dalam file yang sama. Saat menggunakan file yang berbeda, itu pada dasarnya tidak mungkin.

Anda harus mengusulkan fitur itu ke spesifikasi YAML itu sendiri.

Diskusi ini berujung pada:

• Bagaimana docker-compose -f file.yml jauh lebih baik daripada docker-compose -f file.yml -f file_extension.yml ?
• Atau: wiring di level perintah _vs_ wiring di level file.

Hanya ketika bekerja pada baris perintah, ketidaknyamanan menjadi nyata. Kita harus mengakui itu sebentar. Segala sesuatu yang lain adalah scriptable, anyway.

Jika itu argumen sebenarnya, maka docker-compose up service memiliki semantik yang lebih baik daripada docker-compose -f service.yml up : mendefinisikan semua yang diperlukan untuk pengembangan lokal (alias pada baris perintah) di docker-compose.override.yml .

Semantik yang diberikan sangat bersih dan dipikirkan dengan matang. Mengadopsi service.yml _untuk penggunaan baris perintah_ mungkin berarti menurunkan UX. Ada argumen lain untuk itu: meskipun jelas pada pandangan pertama, apa itu docker-compose.yml , service.yml bisa berupa apa saja, benar-benar apa saja.

Disclaimer: Pendapat yang provokatif. :wink: Saya tidak memperhitungkan setiap kemungkinan kasus penggunaan...

Setelah diskusi panjang ini tidak yakin apakah itu akan berhasil. IMHO, ekstensi itu keren dan setidaknya harus hati-hati ditinggalkan dan kemudian dibahas alih-alih hanya membuangnya.

Saya pikir satu hal yang bisa kita lakukan adalah meningkatkan cerita dokumentasi tentang v2 vs. v3. Banyak yang berasumsi bahwa v3 menggantikan v2, tetapi itu tidak sepenuhnya benar. Keduanya menerima fitur baru yang berfokus pada kasus penggunaannya. Masalah GH ini dimulai sehingga kami dapat berdiskusi tentang fitur masa depan apa yang diperlukan untuk beralih dari docker-compose ke Swarm, dan bagaimana meningkatkan dokumen untuk menggunakan docker-compose, format file penulisan, dan tumpukan Swarm bersama-sama. Extends masih berfungsi dengan baik di v2.4 terbaru. Mudah-mudahan, saya dapat membantu menawarkan informasi tentang solusi apa yang kami miliki saat ini:

v2: Hanya untuk cli komposisi buruh pelabuhan. Alur kerja pengembangan difokuskan pada satu mesin dan mesin. Juga bagus untuk alur kerja build/test CI. Cabang versi ini menerima fitur baru pada Desember 2017 di v17.12

v3: Ideal untuk tumpukan Swarm/Kube, dengan konsep multi-node dan mempertahankan dukungan untuk sebagian besar fitur cli komposisi buruh pelabuhan.

Jika Anda tidak menggunakan tumpukan Swarm atau Docker Enterprise Kubernetes, tidak ada alasan untuk menggunakan v3 . Tetap menggunakan v2.4, dan Anda mendapatkan semua fitur cli komposisi buruh pelabuhan termasuk ekstensi, depend_on, bidang ekstensi, dan bahkan depend_on dengan pemeriksaan kesehatan (untuk menghindari skrip wait-for-it).

v3 dibuat untuk mencoba dan menggabungkan fitur-fitur dari dunia cli penyusun docker mesin tunggal dengan dunia cluster multi-simpul. Tidak semua fitur v2 (seperti depend_on) masuk akal dalam sebuah cluster. Fitur lain (seperti perluasan) belum berhasil masuk ke v3, kemungkinan karena sebelum v3 ada, semua kode ada di Python yang ditulis buruh pelabuhan, dan untuk v3.0 untuk mendukung Swarm, mereka harus menulis ulang itu di buruh pelabuhan cli Go, dan sekarang mereka menulisnya lagi di daemon mesin untuk akhirnya membuat Swarm stacks API, yang belum ada.

Bagi mereka yang baru mengetahui masalah ini, perhatikan juga banyak pekerjaan yang dilakukan untuk menyelesaikan berbagai masalah konfigurasi, templating, dan alur kerja tim sejak rilis 3.0:

• 3 fitur yang saya bahas secara singkat di artikel ini (env vars, templating, dan compose scope)
• menimpa file, konfigurasi docker-compose , dan file .env
• template eksperimental docker-app dan cli pengemasan. LIHAT INI
• GUI komposisi buruh pelabuhan yang akan datang (penggoda di keynote DockerCon 2018)

Dokumen di https://docs.docker.com/compose/extends/#extending -services harus menekankan dengan warna merah fakta bahwa kata kunci extends dihapus di v3, karena lebih penting daripada hanya _note_.
Saya bermigrasi dan membaca sekilas dokumen mengapa tidak lagi berfungsi, kemudian mengikuti beberapa masalah tertutup sebelum berakhir di sini, lalu kembali ke dokumen asli dan memperhatikan kata-katanya.

Kata kunci extends didukung dalam format file Compose sebelumnya hingga Compose file versi 2.1 (lihat perluasan di v1 dan perluasan di v2), tetapi tidak didukung di Compose versi 3.x.

Bisa direfrase menjadi:

Kata kunci extends telah dihapus di Compose versi 3.x, tetapi masih didukung dalam format file Compose sebelumnya hingga Compose file versi 2.1 (lihat perluasan di v1 dan perluasan di v2).

Ini adalah perbedaan kecil, tetapi yang mudah diabaikan saat membaca sekilas dokumen.

@krisrp PR dimulai ^^^

Terima kasih @BretFisher

Apakah ada rencana untuk mengubah nama v2 menjadi "version: docker-cli" dan v3 menjadi "version: swarm/kube"?
Akan lebih masuk akal untuk membedakannya seperti ini, mengingat bagaimana v3 menggantikan v2 di sebagian besar skema pembuatan versi lainnya. Saat ini keduanya dipertahankan dan divergen, jadi kecuali saya salah sepertinya mereka berdua akan ada untuk sementara waktu.

@krisrp Sebaliknya, alasan penambahan nomor versi utama adalah untuk menandakan perbedaan dalam kompatibilitas.

@ cpuguy83 Saya tidak menyiratkan sebaliknya. Maaf karena tidak lebih jelas atau eksplisit.
IIRC Gnome 2 & 3 juga mengalami kebingungan ini bertahun-tahun yang lalu ketika garpu independen masing-masing dipertahankan.

Saya tidak ingin menggagalkan utas ini untuk membahas semantik versi (permainan kata yang buruk), jadi saya akan berhenti di situ. Posting @ BretFisher minggu lalu tentang meningkatkan dokumentasi pada v2 vs v3 akan membantu saya dan mungkin orang lain.

@shin- @cpuguy83 Melihat masalah ini lebih dari setahun kemudian, _apakah alasan untuk tidak menambahkannya kembali di versi 3?

Saya tidak dapat menemukan banyak tentang itu, selain "kita bisa melakukannya secara berbeda" (tetapi tidak ada solusi yang lebih baik yang ditawarkan)
Apakah ada batasan teknis? Atau hanya kurangnya permintaan tarik?

Bagaimanapun, file compose 2.1 saya masih berjalan dengan baik.

Tidak hanya itu, tetapi changelog mengatakan "ini telah dihapus, lihat 'cara meningkatkan' untuk detailnya". Saya melihat "cara meningkatkan" untuk, Anda tahu, detail tentang cara meningkatkan, dan apa yang dikatakan adalah "lihat 'memperluas layanan' untuk detailnya". Saya pergi ke "memperluas layanan" dengan berpikir saya akhirnya akan melihat cara untuk memperluas file saya, hanya untuk melihat "ini telah dihapus, lihat changelog untuk detailnya".

Pada titik ini, ini tampak seperti lelucon kejam yang dimainkan oleh penulis dokumentasi.

Pada akhirnya, format "tumpukan" tidak dikontrol di sini dan merupakan bagian dari CLI Docker.

Saya pribadi tidak tahu alasan mengapa itu dikeluarkan dari v3... Saya juga tidak berpikir saya pernah melihat orang yang benar-benar mencoba untuk menambahkannya.
Mungkin lebih baik untuk membawa ini ke buruh pelabuhan/klien ... bahkan mungkin hanya PR dengan perubahan dokumen tingkat tinggi yang bertindak seolah-olah fitur itu ada sehingga dapat didiskusikan dan implementasinya dapat ditambahkan setelah desain disetujui .

Pada dasarnya, jika seseorang menginginkannya, buatlah PR. Saya menyarankan perubahan dokumen hanya untuk memastikan Anda tidak membuang banyak waktu jika ditolak ... karena sekali lagi saya tidak yakin mengapa itu dihilangkan dari v3.

Sama seperti di atas. Menunggu ini diselesaikan sebelum menggunakan docker-compose lagi.

+1 tolong perbaiki ini, kami telah memperluas file penulisan berbasis dan tidak dapat menggunakan penulisan untuk swarm karena itu.

+1 untuk fitur ekstensi

Ada berita tentang ini?

Masih menunggunya

Sama disini. Masih menunggu.

Perubahan apapun?

Apakah pernah ada alasan yang diberikan mengapa itu diambil?

Pada Senin, 5 Agustus 2019, 11:10 Jaykishan, [email protected] menulis:

Perubahan apapun?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/31101?email_source=notifications&email_token=ABOE6GA4CXY6ESMZMTDSFGDQC74CZA5CNFSM4DANZGS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5FLWZ3GOZLORLment-5WZHJKTDN5
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABOE6GCEFFJ3SOLDWRWX2IDQC74CZANCNFSM4DANZGSQ
.

Perubahan apapun?

jadi.. hampir 3 tahun...
tapi saya masih punya harapan itu akan mendarat :D

Perlu ada semacam alternatif untuk ekstensi jika tidak kembali. Mengapa tidak mengizinkan layanan abstrak? Format file akan datar dan semua deklarasi layanan akan berada dalam satu file. Anda dapat menggunakan layanan abstrak bersama dengan kemampuan yaml untuk menambahkan alias untuk sebuah simpul (melalui & ) menggunakan kembali alias tersebut melalui operator <<: .

Kenapa 3 tahun!! sepertinya Anda bekerja dan fokus pada hal-hal yang tidak dipedulikan oleh siapa pun

ada update tentang ini?

Ini menyedihkan. Terraform menggunakan komposisi - jadi itu bisa dilakukan, mengapa komposisi tidak dapat mengikuti praktik desain yang baik ini?!
Komposisi Modul Terraform
Praktik Terbaik Terraform

"menyedihkan", bagus.

@Cristian-Malinescu Silakan, terapkan.
Ini adalah perangkat lunak sumber terbuka dan gratis.

Alih-alih mengeluh seperti orang lain dalam obrolan ini.
Itu tidak menambah nilai apa pun di sini, sungguh.
Seperti yang dikatakan beberapa kali tidak ada yang ingin menerapkan ini sejauh ini,
jadi itu hanya masalah orang lain harus memperbaiki k, terima kasih.

@luckydonald Terima kasih untuk mendorong @Cristian-Malinescu dengan jawaban yang mudah/pasif-agresif, itu, seperti selalu tidak membantu. @Cristian-Malinescu Itu bisa dilakukan seperti yang sudah dilakukan sebelumnya tetapi dihapus, pasti ada (saya harap) ada alasannya. Apakah ada orang di utas ini sebenarnya di tim pembuat buruh pelabuhan sehingga dia dapat menjelaskan urusan?

Skim thread dan memanfaatkan fungsionalitas YAML yang didukung telah disebutkan.

Pikir contoh ini mungkin membantu.

@nomasprime terima kasih atas penemuan itu! Saya memutuskan antara v2 dan v3 untuk proyek saya, dan ini menyelesaikan dilema besar di utas ini. Terkejut bahwa solusi alternatif ini tidak disebutkan dalam dokumen resmi untuk fitur layanan yang diperluas.

Bagus, kedengarannya seperti kesempatan bagus untuk menggunakan tautan Request docs changes di bilah navigasi kanan halaman dokumen.

@nomasprime Ya, ide itu sudah ada di utas ini sebelumnya.

Jika itu dapat digabungkan dengan mekanisme pemuatan file untuk file yml lainnya, hanya itu yang diperlukan untuk memiliki semua fungsi depends .

Lihat di atas, misalnya https://github.com/moby/moby/issues/31101#issuecomment -413323610

Itu tidak akan sangat _dapat dibaca_, tetapi setidaknya _mungkin_.

@nomasprime terima kasih atas penemuan itu! Saya memutuskan antara v2 dan v3 untuk proyek saya, dan ini menyelesaikan dilema besar di utas ini.

@arseniybanayev Artikel di media mengatakan tentang v3 saja, tetapi versi v2 yang lebih baru docker-compose dan bukan swarm (dan v3 tidak mendukung beberapa fitur v2 seperti membatasi memori kontainer )

dan v3 tidak mendukung beberapa fitur v2 seperti membatasi memori kontainer

v3 mendukung pembatasan memori, tetapi bidangnya di bawah deploy -> resources -> limits https://docs.docker.com/compose/compose-file/#resources

@thaJeztah maksud saya, untuk docker-compose (karena saya tidak menggunakan swarm dalam proyek yang saya maksud di komentar saya sebelumnya). Penyebaran IIRC hanya untuk swarm, bukan?

Apakah masuk akal untuk membuat konfigurasi terpisah untuk swarm dan lokal? Sepertinya kedua orang ini saling bertentangan. Maklum Docker ingin penggunaan swarm ditingkatkan, tetapi banyak orang hanya menggunakan compose untuk pengembangan lokal.

Saya tidak pernah menggunakan swarm and run container dalam produksi dengan ECS, k8s, atau GAE.

Sebagian besar opsi harus dapat diterjemahkan / dapat digunakan untuk layanan swarm/kubernetes dan untuk container yang digunakan melalui compose. Saya harus memeriksa mengapa batas memory tidak berlaku untuk docker-compose

masih kehilangan fitur perluasan, tetapi untuk kasus penggunaan utama saya, saya beralih ke beberapa file penulisan buruh pelabuhan melalui COMPOSE_FILE env. Saya menggunakannya sebagian besar untuk menggunakan basis docker-compose.yml yang sama untuk dev dan prod dengan kata sandi atau konfigurasi yang berbeda.

contoh:

• di dev: export COMPOSE_FILE= docker-compose.yml` # default
• pada prod: export COMPOSE_FILE= docker-compose. yml:docker-compose.prod.yml `# menggunakan kedua file yaml

Di docker-compose.prod.yml saya hanya menimpa env vars dengan kata sandi prod.

Pengaturan ini sederhana dan saya tidak perlu selalu menambahkan beberapa "-f" ke perintah docker-compose . Saya hanya perlu mengatur perbedaan COMPOSE_FILE env var di komputer dev dan server dan git mengabaikan file docker-compose.prod.yml.

Masih menunggu :)

Saya telah menggunakan ini sebagai cara untuk memperluas:

docker-compose \
  -f ./docker/base.yml \
  -f ./docker/extended.yml \
  up

Tetapi memperpanjang dalam file akan lebih baik, tidak perlu skrip bash tambahan.

Saya juga telah menggunakan ini untuk memperluas secara dinamis dari skrip bash:

extended_docker_compose="
  version: '3.5'
  services:
    my-service:
      restart: always
"

echo "$extended_docker_compose" | docker-compose \
  -f ./docker/base.yml \
  -f /dev/stdin \
  up

@dave-dm itu adalah penggantian lama biasa!

Saya percaya ini adalah usecase valid yang potensial untuk ekstensi

https://github.com/NerdsvilleCEO/devtools/blob/master/doctl/docker-compose.yml#L10

Saya memiliki pembungkus docker-compose yang saya gunakan untuk env layanan https://github.com/nowakowskir/docker-compose-wrapper

EDIT: Kasus penggunaan lain yang mungkin adalah seseorang memiliki tumpukan LAMP/LEMP dan mereka ingin memperluas layanan tersebut untuk digunakan dengan layanan tertentu seperti wordpress

Masih menunggu sejak 2017 sambil menjelajahi alternatif komposisi buruh pelabuhan.

@nomasprime Ya, ide itu sudah ada di utas ini sebelumnya.

Jika itu dapat digabungkan dengan mekanisme pemuatan file untuk file yml lainnya, hanya itu yang diperlukan untuk memiliki semua fungsi depends .

Lihat di atas, misalnya #31101 (komentar)

Itu tidak akan sangat _dapat dibaca_, tetapi setidaknya _mungkin_.

@luckydonald terima kasih telah menunjukkan. Anehnya tidak ada fungsi YAML include bawaan , pasti akan menyelesaikan banyak masalah.

Sepertinya akan cukup mudah untuk menerapkan solusi pihak ketiga, jadi tidak yakin mengapa ini belum dibawa ke v3

Sedikit pengingat bahwa banyak orang akan menyukai fitur ini :)

Apa alasan untuk tidak porting ke v3 btw?

Saya lupa tetapi apakah ada alasan sebenarnya mengapa itu diambil?

Pada Rabu, 6 Mei 2020, 23:14 Julien Marechal, [email protected] menulis:

Sedikit pengingat bahwa banyak orang akan menyukai fitur ini :)

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/31101#issuecomment-624919070 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABOE6GGDIVGATP734YJA4UTRQHOLJANCNFSM4DANZGSQ
.

Cara jangkar yaml menangani kasus penggunaan ini agak merepotkan dibandingkan dengan extend . Kekuatannya, menurut pendapat saya, sebagian besar berasal dari penggabungan elemen secara rekursif. Jangkar membuat Anda mungkin 75% dari jalan ke sana--mereka tidak menggabungkan yaml secara rekursif; semua penggabungan Anda terjadi di tingkat atas. Mereferensikan template layanan berlabuh dan kemudian mendefinisikan ulang blok environment akan mengakibatkan penimpaan blok lingkungan layanan berlabuh alih-alih penggabungan. Anda harus mengaitkan dan mereferensikan setiap kamus ke bawah pohon kamus rekursif untuk mencocokkan perilaku kata kunci extend .

Sebuah contoh:

# anchors for the service, environment, deploy, and deploy.placement blocks
# you'll need an anchor for every dict that you want to merge into
x-common-app: &common-app
  image: app:1.0
  environment: &common-app-environment
    common_option: a
    overwrite_option: b
  deploy: &common-app-deploy
    max-replicas-per-host: 3
    placement: &common-app-deploy-placement
      constraints:
        - 'node.labels.app_host==true'

services:
  myapp: << *common-app
    environment: << *common-app-environment
      foo: bar
      baz: xyzzy
      overwrite_option: quz
    deploy: << *common-app-deploy
      replicas: 15
      placement: << *common-app-deploy-placement
        preferences:
          - spread: node.labels.region

# The above yields the following:
services:
  myapp:
    image: app:1.0
    environment:
      common_option: a
      overwrite_option: quz
      foo: bar
      baz: xyzzy
    deploy:
      replicas: 15
      max-replicas-per-host: 3
      placement:
        constraints:
          - 'node.labels.app_host==true'
        preferences:
          - spread: node.labels.region

Ini mungkin tidak terlihat begitu mengganggu dalam contoh ini, tetapi akan mengganggu dan kurang terbaca jika Anda membuat template beberapa (10+) layanan dari satu blok ekstensi.

Dalam pikiran saya, skenario yang ideal adalah kombinasi dari pendekatan jangkar yaml dan pendekatan extend --allow extend hanya dari blok bidang ekstensi awalan x- tingkat atas, dengan karakteristik penggabungan yang lebih cerdas.

Di organisasi saya, kami menemukan jangkar yaml sedikit tidak rapi secara sintaksis sehingga pada dasarnya kami mengimplementasikan kembali fitur extend dalam skrip python eksternal. Itu berhasil bagi kami, tetapi itu cara yang lemah untuk berurusan dengan sesuatu. Demikian pula kami harus membuat perkakas eksternal kami sendiri untuk menangani penghapusan depends_on untuk tumpukan v3/Swarm.

Saya telah melakukan banyak gitlab CI YAML akhir-akhir ini. Ini memiliki fitur-fitur ini, yang sangat bagus untuk mencapai templat dan konfigurasi akhir yang dapat dibaca dan dikelola:

• Anda dapat menyertakan file YAML lainnya (baik untuk template)
• Anda dapat memperluas (bahkan di seluruh proyek/menggunakan sumber daya jarak jauh melalui https). Dokumentasi perluasan menjelaskan dengan tepat apa yang dijelaskan @a-abella untuk format penulisan.
• Anda juga dapat "bersembunyi" agar tidak dianggap sebagai barang asli. Dalam format penulisan x- , dalam gitlab CI ini adalah . sebagai gantinya.

Ini adalah kumpulan fitur yang tepat yang membuat file-file ini tertahankan.

Saya sampai pada masalah ini dari docker docker, dalam kasus saya, saya ingin membuat template pengaturan docker-compose , dan sebagai 'solusi' saya mengikuti saran di atas dan memutuskan untuk mencari program templating yang ada. Saya tidak akan mendapatkan jam kami kembali jadi saya merinci sedikit dari apa yang saya temukan di sini, terlepas dari diskusi apa pun tentang permintaan fitur aktual ini, namun, mungkin mereka yang terlibat akan merasakan penggunaan sistem templat berbasis YAML untuk menghasilkan file penulisan daripada mengintegrasikan fitur ini ke dalam docker-compose itu sendiri mungkin lebih tepat dalam hal enkapsulasi dan memilih alat yang tepat untuk pekerjaan itu.

Untuk beberapa konteks, saya menggunakan proxy terbalik dasar dengan Let's Encrypt dan beberapa wadah aplikasi (Nextcloud untuk saat ini, satu untuk saya, dan beberapa yang terpisah untuk teman) - dalam hal ini, saya ingin membuat template wadah Nextcloud jadi bahwa saya menghindari kesalahan dan duplikasi dengan penekanan tombol untuk pengaturan yang sangat mirip. Paket-paket berikut adalah apa yang saya coba:

• ytt
• Dhall
• ISYARAT
• Jsonnet

ytt tampaknya sangat komprehensif dan merupakan satu-satunya pilihan untuk menggunakan YAML secara native. Tampaknya kuat dan alat yang tepat untuk pekerjaan itu, dan menggunakan Starlark, superset Python, langsung di dalam file YAML untuk melakukan pemrosesan. Namun tidak lama kemudian, template menjadi sangat berantakan, dan mengotori fragmen kode dan fragmen YAML, ditambah pencampuran tipe data Python seperti kamus dan array dan fragmen YAML (yang tampaknya agak diproses seperti teks, sedikit seperti menggunakan mesin templat HTML yang mengeluarkan tag seperti string) akhirnya menghasilkan terlalu banyak kesalahan dan file terlalu berantakan. Dhall juga tampaknya sangat komprehensif dan menggunakan bahasa asli yang unik yang dapat di-output ke berbagai format; Tampaknya lebih seperti bahasa metaprogramming daripada sistem templat, namun mengingat sintaksnya fungsional dan diketik dengan cukup ketat, itu dengan cepat menjadi lebih kompleks daripada yang layak untuk templat sederhana untuk YAML tidak terstruktur. Karena apa yang tampak seperti campuran JSON dan Haskell, itu membutuhkan terlalu banyak pemikiran untuk mengerjakan apa yang perlu saya lakukan ke dalam bahasa.

Menariknya, sesuatu yang sulit dengan Dhall dan ytt menggunakan nama bidang yang diparameterisasi, keduanya akan bekerja cukup baik jika tidak, tetapi saya harus membuat nama instance saya muncul di nama layanan dan nama volume, dan dalam kedua pencapaian ini ini agak jelek; menggunakan argumen untuk nilai dalam hash itu mudah, tetapi menggunakan argumen itu atas nama kunci itu berantakan atau saya tidak dapat menemukan cara melakukannya dengan rapi, ditambah Dhall memberlakukan keamanan tipe dan ini bertentangan dengan konsep itu. Dengan Jsonnet itu sederhana seperti menempatkan ekspresi dalam tanda kurung siku.

CUE dan Jsonnet keduanya berorientasi JSON, namun menjalankan ini melalui konverter tidak sulit sama sekali, dan sepertinya lagi, seperti Dhall, CUE memiliki banyak fitur canggih dan lahir dari kekurangan di Jsonnet, namun sebagian dari dokumentasi , menjadi jelas itu sudah berlebihan; mungkin dengan lebih banyak waktu untuk mempelajarinya dengan benar, itu akan menjadi opsi yang lebih unggul, tetapi tampaknya CUE lebih berorientasi pada validasi dan skema daripada pekerjaan templat sederhana dan jadi saya dengan cepat pindah ke Jsonnet dan menyelesaikan pekerjaan dengan cukup cepat.

Akhirnya, hanya setelah saya menyelesaikan semua ini, saya menyadari sepanjang waktu saya telah membandingkan alat-alat ini dengan kesederhanaan tag Liquid atau template HTML serupa, bahwa saya sebenarnya bisa saja menggunakan Liquid di tempat pertama. Saya hanya menggunakannya dalam konteks situs Jekyll, jadi tidak pernah terjadi atau mendapatkan paket mandiri, namun dengan perulangan dan daftar dasar, dan kemampuan untuk mengevaluasi ekspresi langsung ke teks di tempat, ini mungkin akan terjadi telah jauh lebih baik juga untuk pekerjaan itu; Jsonify mungkin lebih unggul untuk JSON, tetapi Liquid dapat beroperasi dalam YAML murni sehingga file menjadi lebih mudah dibaca lagi.

+1 docker-compose adalah salah satu inspirasi di balik solusi dipesan lebih dahulu yang telah saya terapkan di tempat kerja sejak tiket ini dibuat untuk mendukung migrasi sejumlah besar envs pengujian ke k8s. Saya sangat berhati-hati untuk menghindari lonceng dan peluit tetapi cukup cepat membenarkan fitur analog. Diskusi filosofis (komposisi versus pewarisan, dll.) Bagi saya tampak seperti gangguan dari akal sehat (dengan manfaat melihat ke belakang - masih belum terselesaikan hampir 3 tahun kemudian). Jelas dibutuhkan oleh orang-orang yang mungkin terus menggunakan docker-compose.

+1 :+1:

Saya menggunakan fitur ini sebelumnya untuk lingkungan dev / test / ci , di mana saya dapat memperluas dari file penulisan di jalur subdirektori ./config/{dev,test,ci}/compose.yaml . Saya akan memiliki .env yang memiliki COMPOSE_ENV=dev , tetapi pengembang dapat menimpa, dan jelas saya akan menimpa ci .

Saya terkejut dengan mencela fitur tersebut dan tidak menggantinya dengan sesuatu yang dapat melakukan hal serupa. Mungkin izinkan kami menggunakan jinja2 dan melakukan apa yang kami inginkan. Saya harap Docker-Compose kurang anti-KERING. :'(

Tampaknya extends didukung oleh docker-compose sejak v1.27 (https://github.com/docker/compose/pull/7588).

Satu kasus penggunaan di mana saya sering menggunakan fitur ini, adalah membuat versi gambar buruh pelabuhan ke kode. File pembuatan docker dev dan prod saya keduanya diperluas dari docker-images.yml di mana hanya layanan dasar yang terdaftar dan versi gambar layanan yang ditandai.

Tidak menemukan solusi mudah untuk ini di v3.