Nama proyek tidak penting. Saya suka ide nama proyek acak. Bahkan lebih baik - dapatkah kita membuat hash dari path ke fig.yml dan menggunakannya?

Menurut saya nama proyek itu cukup penting. Jika Anda ingin dapat melakukan apa pun dengan gambar dalam pipeline CI, Anda perlu mengetahui nama proyek agar dapat memberi tag ulang sebagai sesuatu yang lain.

Mampu mengganti nama proyek dari variabel lingkungan membuatnya mudah untuk membuat ini unik, dan dapat diprediksi. Saya pikir apa pun yang terjadi, kita perlu mendukung penggantian dari variabel lingkungan.

Saya menyukai gagasan membuat nama proyek dapat dikonfigurasi dari sebuah file. Saya pikir diskusi serupa terjadi di (# 45). Memiliki nama proyek di .fig/project-name sepertinya akan menghasilkan banyak file yang sangat kecil. Saya pikir akan lebih mudah untuk hanya memasukkannya ke dalam fig.yml itu sendiri (seperti yang disarankan di # 45, dan salah satu pekerja galangan membuat proposal).

Apa keuntungan meletakkannya di direktori dan file terpisah?

Alasan untuk meletakkannya di file terpisah memiliki beberapa alasan, saya akan mencoba menjelaskan pemikiran saya di balik ini;

• Untuk mempertahankan nama yang digunakan untuk _mulai_ proyek (yaitu, --project-name=foobar ), yang dapat berbeda dari nama-proyek otomatis.
• Memiliki beberapa contoh atau _versions_ dari sebuah proyek yang berjalan di server yang sama, tanpa saling bentrok
• Atau, singkatnya, .fig/project-name memegang nama _that instance_ dari proyek tersebut.

Mungkin file tersebut harus bernama instance-name atau serupa.

Saya sangat menyukai ide untuk membuat nama proyek dapat dikonfigurasi dari sebuah file

Meskipun _possible_ untuk melakukan ini dengan proposal ini (dengan membuat file project-name secara manual), kasus penggunaan utama saya adalah membuat _fig_ membuat file untuk menyimpan nama yang digunakan.

akan menghasilkan banyak file yang sangat kecil.

Benar, alternatifnya adalah melewati direktori .fig , namun, jika ada hal tambahan yang diperlukan di masa mendatang, file tambahan dapat ditambahkan tanpa mengacaukan root proyek Anda. Git melakukannya serupa dan menurut saya ini pendekatan yang bersih.

Saya pikir akan lebih mudah untuk memasukkannya ke dalam fig.yml

Saya pikir kedua pilihan bisa saling melengkapi; gunakan nama dari fig.yml sebagai default jika nama tidak diganti oleh flag atau env-variable. Masukkan nama yang sebenarnya digunakan untuk _mulai_ proyek di dalam .fig/project-name

Mampu mengganti nama proyek dari variabel lingkungan membuatnya mudah untuk membuat ini unik, dan dapat diprediksi. Saya pikir apa pun yang terjadi, kita perlu mendukung penggantian dari variabel lingkungan.

Ingin tahu; bagaimana Anda menangani pengelolaan banyak proyek? Yaitu cd project-a && fig ps lalu cd project-b fig <something> ?

Terima kasih atas tanggapan Anda!

Ingin tahu; bagaimana Anda menangani pengelolaan banyak proyek?

Saya biasanya menjalankan fig dari python-tox , yang memungkinkan saya mengatur lingkungan, jadi saya tidak pernah benar-benar mengaturnya di shell saya. Saya juga cenderung menggunakan tmux, jadi saya memiliki kerangka yang berbeda untuk setiap proyek.

Saya pikir kedua opsi bisa saling melengkapi

Keren, saya setuju.

Saya tidak tahu apakah saya dijual dengan harga .fig/instance-name vs katakanlah .fig-instance.yml yang dapat berisi contoh penggantian tertentu, tetapi saya pikir ini lebih merupakan poin kecil.

Memikirkan nama proyek; Jika saya memahami situasi Anda dengan benar, penting untuk dapat mengontrol _images_ yang diproduksi, misalnya myapp:build12345 , atau juga nama _containers_? Hanya untuk "merasakan" situasi Anda.

Pikiran saya di balik nama-proyek "acak" adalah, selama Fig dapat menemukan wadah untuk sebuah proyek, nama yang terlihat bagus tidak penting. Jika saya, sebagai pengguna, dapat mengakses wadah layanan melalui nama-layanannya (misalnya fig stop web ), nama wadah sebenarnya tidak masalah.

Bahkan telah berpikir bahwa ara dapat melacak kontainer berdasarkan ID di penyimpanan lokal di dalam direktori .fig (yang bisa menjadi keuntungan kinerja pada mesin dengan banyak kontainer yang berjalan). Tapi itu benar-benar sesuatu untuk masalah terpisah.

Ada pendapat tentang "secara implisit" membuat file 'nama-proyek' atau "secara eksplisit" melalui fig init ? Mungkin jika saya punya waktu selama liburan yang akan datang, saya dapat bereksperimen sedikit (tidak pernah mengkodekan apa pun dengan Python, jadi ini akan menjadi _really_ eksperimental :))

penting untuk dapat memiliki kontrol atas gambar yang sedang diproduksi, misalnya myapp: build12345 , atau juga nama containernya?

Saya kira gambar adalah yang paling penting, tetapi mampu memastikan bahwa nama kontainer tidak bertentangan juga sangat penting pada host bersama. Saya melihat proposal ini sebenarnya bertujuan untuk menangani masalah itu juga.

Namun menurut saya, nama container yang dapat diprediksi masih penting. Saya dapat memikirkan beberapa tugas yang penting bagi sistem eksternal (bukan hanya gambar) untuk dapat mengidentifikasi wadah dengan nama:

• skrip pembersihan untuk menghapus penampung lama, mampu mengidentifikasi proyek apa yang membuat penampung
• debugging / memeriksa kontainer

Keduanya cukup mudah sekarang karena saya sudah tahu apa nama wadahnya. Jika saya harus mencari nama, itu agak lebih rumit.

Bahkan telah berpikir bahwa ara dapat melacak kontainer berdasarkan ID di penyimpanan lokal di dalam direktori .fig

Memang benar ini bisa menjadi keuntungan kinerja, tetapi saya khawatir ini adalah pendekatan yang salah. Menambahkan status persisten apa pun ke ara memperkenalkan kemungkinan banyak bug (yang menyertai status). Saya lebih suka melihat ini ditangani oleh sistem pelabelan di dockerd. Jika fig hanya dapat memberi label pada container dan kemudian melakukan query untuk semua container dengan label tersebut, ia menyimpan semua status di satu tempat (dockerd). Saya tahu ada pembicaraan tentang ini di beberapa titik, saya tidak yakin apakah itu ada di peta jalan.

Ada pendapat tentang "secara implisit" membuat file 'nama-proyek' atau "secara eksplisit" melalui fig init?

Saya kira secara implisit akan lebih kompatibel ke belakang. Saya ingin menghindari fig init kecuali benar-benar diperlukan. Alih-alih menggunakan basedir, saya bisa melihatnya secara implisit membuat nama proyek <basename>-<4 digit random id>

saya hanya bisa mengatakan jika ara mulai menghasilkan nama acak sekarang saya akan beralih darinya karena saya menjalankan 1000+ kontainer pada satu host dan ketika saya tidak dapat mengidentifikasi mereka dengan nama lagi, itu bukan apa-apa bagi saya.

@ frank-dspeed terima kasih telah menambahkan use-case Anda. Jika saya mengerti dengan benar, Anda _mulai_ container Anda dengan ara, tetapi _ "kelola" _ secara langsung melalui Docker setelah itu, gunakan konvensi penamaan yang digunakan Fig?

Mungkin ini juga menarik bagi Anda: https://github.com/docker/docker/pull/9882 - memiliki meta-data akan menawarkan lebih banyak cara untuk mengidentifikasi wadah, tidak hanya namanya.

ah ya saya banyak melakukan proposal seperti itu misalnya hanya menambahkan fild baru dan itu tetapi saya mengakhiri kasus itu dengan hanya menambahkan ENV dan kemudian saya memilikinya sebagai costum fild saya dapat menguraikannya: panah:

Saya pikir mengelola ketidakjelasan nama proyek seharusnya tidak menjadi tanggung jawab ara.

ketika saya memahami proposal Anda dengan benar, pembuatan nama acak akan membuat FIG_PROJECT_VARIABLE dan --project-name -option tidak berguna. yang berguna untuk layanan 'template'.

Saya pikir mengelola ketidakjelasan nama proyek seharusnya tidak menjadi tanggung jawab ara.

Saya tidak yakin; Gambar "diam-diam" menimpa wadah proyek lain karena jika kebetulan berada di direktori dengan nama yang sama terkadang tidak menyenangkan.

ketika saya memahami proposal Anda dengan benar, pembuatan nama acak akan membuat FIG_PROJECT_VARIABLE dan --project-name-option tidak berguna. yang berguna untuk layanan 'template'.

Setelah pembahasan di atas, saya pikir hal seperti ini akan berhasil

• Jika --project-name disediakan, gunakan itu (dan tulis / perbarui .project-name ? Tidak yakin)
• Tidak ada --project-name yang disediakan, tetapi FIG_PROJECT_NAME adalah, gunakan FIG_PROJECT_NAME (dan tulis / perbarui ke .project-name ?)
• Tidak satu pun di atas, tetapi .project-name disetel, gunakan .project-name
• Bukan dari salah satu di atas; buat nama _random_ dan tuliskan ke .project-name

dari perspektif seseorang yang menggunakan ara dalam skrip yang menangani nama dan meneruskannya ke ara, menyimpan nama di lokasi proyek (yang dalam kasus saya lebih merupakan templat) tidak masuk akal.

dan tetap saja, saya merasa sangat intuitif bahwa nama direktori digunakan dalam nama kontainer yang dihasilkan ketika saya baru saja menjalankan fig up .
dan katakanlah, Anda melihat docker ps -a , itu tidak akan terlalu membantu jika diisi dengan nama acak.

akankah opsi --random-name membantu dalam situasi Anda?
Selain itu saya pikir kemampuan untuk menambahkan beberapa [a-zA-Z0-9_].* untuk mencerminkan beberapa namespacing akan berguna untuk penerapan yang lebih luas.

Bagaimana dengan menggunakan fig.yml untuk menyimpan informasi seperti itu?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

Dan untuk menjaga BC, di compose / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse Saya sangat menyukai sesuatu seperti yang Anda sarankan. Mungkin Anda ingin menambahkan proposal Anda ke # 45 karena ini mungkin tempat yang lebih baik untuk membahasnya?

untuk mencapai resolusi pada tiket ini? Sepertinya # 1233 yang diusulkan memberi Anda yang terbaik dari kedua dunia dengan membiarkan pengguna memutuskan tindakan yang akan diambil sementara tidak merusak kompatibilitas mundur apa pun.

Awalnya saya ingin nama di docker-compose.yml , tetapi setelah memikirkannya lebih lanjut, saya sangat menyukai gagasan file terpisah.

File terpisah memberi Anda opsi untuk tetap tidak mengontrol versi jika Anda mau (untuk kasus di mana Anda ingin setiap pengguna dapat memiliki nama proyek yang berbeda).

Dengan dukungan jaringan baru, ada permintaan fitur untuk dapat mengkonfigurasi nama jaringan juga (defaultnya adalah nama proyek). Jadi dengan file konfigurasi terpisah kita dapat menyertakan hal-hal seperti nama jaringan default, skala default dll. Semua konfigurasi meta yang bukan bagian dari definisi aplikasi, tetapi masih relevan untuk menjalankan komposisi.

Saya setuju dengan apa yang dikatakan dnephin. Bagaimana dengan file .docker-compose ? Kami dapat mencantumkan opsi default untuk semua argumen baris perintah di sana.

@dnephin sgtm

@mikehaertl Saya menggunakan folder .docker-compose dalam contoh saya, tetapi sebuah file juga dapat bekerja, tergantung pada seberapa banyak informasi yang ingin kita simpan

@thaJeztah Oh, benar, maaf. Saya melewatkan itu.

@mikehaertl baru saja mengganti namanya dari .fig menjadi .docker-compose ;-)

Baik :)

Sebenarnya saya lebih suka file sederhana. Bagaimana dengan gaya ini? Opsi global di atas, opsi perintah khusus di bagian:

project-name = blabla

[build]
no-cache

Beberapa ide untuk informasi semi-terkait yang mungkin ingin kami simpan di file yang sama, atau direktori yang sama:

• nama jaringan (pengguna mungkin menginginkan nama jaringan yang berbeda dari nama proyek. Kami sudah memiliki satu permintaan untuk itu.)
• versi api klien
• tuan rumah buruh pelabuhan
• nilai skala default

Sekarang kami mendukung beberapa file penulisan, mungkin juga menarik untuk menyertakan jalur ke file penulisan untuk digunakan sebagai konfigurasi.

versi api klien

mungkin docker_host ?

Kedengarannya bagus juga (ditambahkan)

Saya baru saja mengalami masalah ini.

Saya berada pada titik di mana struktur dasar dari konfigurasi buruh pelabuhan kami telah diselesaikan, dan sekarang saya mereplikasinya ke layanan lain. Karena semua proyek memiliki struktur yang sama, semuanya menggunakan subdirektori yang sama (dan karenanya, nama proyek default). Yang berarti saya tidak dapat mengumpulkan 2 layanan dengan aman di host yang sama.

Saya mungkin harus mengubah strukturnya sehingga nama direktori proyek akhirnya menjadi default, tapi saya tidak 100% yakin apa yang dilakukan tentang menyalin file pada waktu pembuatan gambar.

Sama di sini, saya memecahkan masalah serupa dengan target Makefile . Tapi tetap saja, ketika Anda ingin menjalankan perintah kustom docker-compose , Anda perlu menggunakan -p customname .

Saat ini saya mencoba mencari cara untuk mencegah setup docker-compose di /home/alice/myproject dan /home/bob/myproject agar tidak menginjak container satu sama lain. Apakah ada cara untuk mendapatkan nama container dari path file lengkap dan bukan hanya dari nama direktori terakhir?

@ chris-martin Ini hanya solusi ...

alias docker-compose="docker-compose -p ${PWD}"

buruh pelabuhan-menulis strip / dari nama proyek, bukan?

Apakah didokumentasikan karakter mana yang diperbolehkan dalam nama proyek?

Saya akhirnya mengubah struktur direktori saya dan meletakkan docker-compose.yml di root proyek, yang merupakan solusi yang cukup layak

Ini memberikan beberapa perlindungan, jika Anda cenderung meletakkan semua repositori git Anda ke dalam direktori yang sama (misalnya, $ HOME, atau $ HOME / proyek), tetapi akan merepotkan jika Anda menggunakan struktur lain (katakanlah, satu direktori per organisasi, seperti saya sering dilakukan), atau jika mesin Anda menggunakan boot2docker, yang cenderung membocorkan informasi ke seluruh pengguna di kotak yang sama kecuali Anda berhati-hati untuk memastikan mesin galangan-galangan memberi Anda VM yang berbeda.

Saya pikir # 2294 atau hanya menjadi lebih higienis dengan mesin buruh pelabuhan juga akan memperbaiki masalah saya.

Saya juga merekomendasikan untuk meletakkannya di root proyek dan memiliki nama folder yang berbeda.

Dalam kasus saya, saya ingin menetapkan nama proyek awal karena saya memiliki mesin bersama di AWS dan meskipun saya memiliki docker-compose.yml di root, pengguna dapat mengkloning repositori ke dalam direktori dengan nama yang berbeda. Jika itu terjadi saat ini, maka mereka mengalami masalah memulai / menghentikan kontainer.

Dengan sintaks v2 ini dapat diterapkan seperti yang disebutkan di https://github.com/docker/compose/issues/745#issuecomment -74028861

Ini sebenarnya hanya container_name_prefix , bukan?

@ rizky_dwi

Ini sebenarnya hanya sebuah container_name_prefix, bukan?

Ini juga digunakan sebagai volume_name_prefix , image_name_prefix dan network_name_prefix , jadi saya rasa project_name adalah istilah yang lebih umum.

.docker-compose terdengar familiar dengan docker-compose.override.yml dalam banyak hal. Selain itu, mengapa memperkenalkan format konfigurasi lain (misalnya ini) ketika kita sudah mendapatkan YAML?
Oleh karena itu, saya mendukung saran @jderusse di # 745 (komentar) untuk menambahkan kunci project_name ke docker-compose.yml , untuk mengaktifkan kasus penggunaan @JosephEarl.

Kustomisasi khusus pengguna sudah dapat diterapkan dengan menggunakan docker-compose.override.yml dan mengecualikannya melalui .gitignore .
Jika diinginkan file timpaan khusus pengguna ketiga, saya sarankan .docker-compose.local-override.yml .

Mengenai struktur YAML, saya sarankan untuk membuat kunci tingkat atas baru yang disebut project , yang berisi project_name , dan mungkin berisi variabel lain di masa mendatang. Ini untuk menghindari pencemaran namespace tingkat atas. Menggambarkan:

project:
  project_name: "your-project"
  network_prefix: "abc"

Perhatikan bahwa, daripada menggunakan network_prefix , mungkin lebih mudah untuk menyesuaikan nama jaringan itu sendiri secara langsung. Seperti yang saya pahami, ada dua kasus:

• Kasus pertama adalah "beri nama unik pada jaringan, tapi saya tidak peduli yang mana tepatnya". Untuk kasus ini, project_name sudah cukup.
• Kasus lainnya adalah jaringan yang dirujuk oleh sistem eksternal. Dalam hal ini, menentukan nama jaringan itu sendiri secara eksplisit mungkin lebih baik.

Proposal yang disarankan di atas kedengarannya bagus untuk saya, saya setuju kami tidak ingin memperkenalkan file konfigurasi tambahan

+1 pada konsep masalah ini
Tetapi juga memberi +1 untuk menggunakan kunci di docker-compose.yml daripada menambahkan file lain ke repo kami.

Untuk meringkas komentar sebelumnya: Satu proposal untuk urutan pencarian nama proyek adalah sebagai berikut; item sebelumnya lebih diutamakan daripada item berikutnya:

1. Gunakan --project-name jika ditentukan
2. Gunakan COMPOSE_PROJECT_NAME jika ditentukan.
3. Gunakan kunci project_name dari docker-compose.yml (atau di mana pun pengaturan itu disimpan).
4. Gunakan basename dari direktori proyek

Saya tidak yakin dengan prioritas 2 vs. 3:

• Untuk konsistensi dengan --project-name , COMPOSE_PROJECT_NAME pasti harus menggantikan project_name: .
• Tetapi: Membuat COMPOSE_PROJECT_NAME lebih diutamakan daripada project_name: memungkinkan untuk secara tidak sengaja menggunakan nama proyek yang salah karena variabel lingkungan sedang disetel; ini mungkin sulit untuk di-debug. Mungkin pesan peringatan bisa menjadi masalah dalam kasus ini?

bagaimana dengan memperkenalkan properti baru container_name_pattern dengan nilai default %(project_name)s_%(service_name)s_%(instance_number)s untuk menyimpan BC
parameter ini memungkinkan kita untuk bebas mengubahnya menjadi hardcodedproject_%(service_name)s_%(instance_number)s dan memperbaiki masalah ini secara pasti

Saya baru saja tiba masalah ini setelah mencari fungsi ini selama 10 menit.

Hal pertama yang saya lakukan adalah mencari kunci yang benar dalam dokumen Referensi File Tulis, jadi +1 untuk project_name kunci docker-compose.yml

: +1: untuk strategi @ cr7pt0gr4ph7

1 untuk strategi @ cr7pt0gr4ph7

Compose memiliki sintaks untuk substitusi lingkungan. Daripada menggunakan variabel lingkungan untuk nama proyek, mungkin membiarkan orang melakukannya sendiri jika mereka peduli?

Di sisi lain, mesin buruh pelabuhan menggunakan bagian akhir untuk memutuskan mesin mana yang akan digunakan untuk membuat build, jadi mungkin nama proyek dan target harus bekerja sama. Hmm, ini yang sulit.

https://github.com/docker/compose/issues/745#issuecomment -182296139 terdengar benar. Variabel lingkungan akan lebih diutamakan daripada nilai dalam file tulis, yang bertindak sebagai default (dengan asumsi nama proyek termasuk dalam file tulis).

Sesuatu yang perlu dipertimbangkan, apa yang terjadi ketika Anda menggunakan beberapa file penulisan yang masing-masing menentukan nama proyek?

Menurut saya ini bukan kesalahan, yang akan memaksa file menjadi "primer" atau "ekstra", yang saat ini tidak terjadi. File apa pun dapat digunakan secara terpisah atau digabungkan dengan file lain.

Mungkin peringatan masuk akal, atau mungkin kita mengabaikannya sepenuhnya (karena nilainya dapat diabaikan dengan menyetel opsi atau variabel lingkungan juga).

Sesuatu yang perlu dipertimbangkan, apa yang terjadi ketika Anda menggunakan beberapa file penulisan yang masing-masing menentukan nama proyek?

Jika Anda melakukan sesuatu seperti docker-compose -f compose1.yml -f compose2.yml up dan kedua file mendefinisikan nama proyek, nama yang digunakan harus dari compose2.yml .

Saya pikir semua orang menggunakan solusi yang saya suka: -) Ie project_name di docker-compose.yaml. Saya hanya ingin menyebutkan kasus penggunaan lain untuk memiliki nama proyek di file docker-compose.yaml:

Di halaman HTTP 500 Internal Server Error dalam proyek saya, saya memberi tahu pengembang cara memperbaiki atau memecahkan masalah, misalnya saya memberi tahu dia bahwa dia dapat zcat database-dump.tgz | docker exec -i projectname_db_1 psql jika server mengetahui bahwa tidak ada database PostgreSQL dan pengguna telah dibuat - dan kemudian saya ingin memilih projectname sendiri, jika tidak, pesan bantuan tidak dapat disalin-tempel ke konsol.

Setuju bahwa akan ada peringatan ketika COMPOSE_PROJECT_NAME mengganti nama proyek di compose.yml - perilaku ini masuk akal berdasarkan perintah Docker yang ada, tetapi tidak terlalu logis atau jelas bagi pendatang baru.

1 untuk strategi @ cr7pt0gr4ph7

Mencoba mencari sesuatu sebelum membuka masalah karena saya tidak dapat menemukan apa pun.
1 untuk project_name dalam file docker.compose.yml. Dengan v2, saya rasa ini semakin masuk akal.

Setuju bahwa akan ada peringatan ketika COMPOSE_PROJECT_NAME mengganti nama proyek di compose.yml - perilaku ini masuk akal berdasarkan perintah Docker yang ada, tetapi tidak terlalu logis atau jelas bagi pendatang baru.

Ini adalah perilaku yang cukup normal untuk variabel lingkungan untuk mengganti pengaturan konfigurasi dan untuk argumen baris perintah untuk mengganti pengaturan konfigurasi dan variabel lingkungan.
Apakah kita benar-benar peringatan untuk itu? Ini tidak seperti ada orang yang secara tidak sengaja membuat variabel lingkungan bernama COMPOSE_PROJECT_NAME .

Apakah boleh membuat PR yang hanya menggunakan project_name dari docker-compose.yml untuk menjalankannya? Atau apakah kita ingin barang ekstra seperti menggunakan nilai project_name dari file yml segera direferensikan?

Bagaimana dengan ini?

version: "2"
project:
    default_name: "app"

Saya akan mengubah implementasi saya (https://github.com/docker/compose/pull/3118) untuk format ini. Tapi saya tidak yakin apakah perlu bagian project ....

+1 ingin sekali melihat fitur ini

@timgriffiths , sepertinya ini dapat dilakukan di RC terbaru dengan menambahkan file lingkungan ke proyek Anda:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

@deizel Jadi saya melihat file lingkungan, tetapi saya masih berpikir ada kasus penggunaan yang baik untuk dapat menentukan nama proyek dalam file tulis.

Dalam situasi kami, kami memiliki Prod, Staging, UAT, Dev membuat file hanya agar kami dapat memulai versi yang berbeda dari tumpukan aplikasi kami, dan terkadang kami ingin mendirikan lingkungan Staging dan UAT pada kelompok yang sama, sehingga saya dapat menggunakan lingkungan variabel atau apa yang tidak tetapi itu bergantung pada pengguna semua mengingat untuk mengatur ini, di mana seolah-olah itu ada di file tulis semuanya akan diperiksa ke dalam repo dan kita bisa menjaga semuanya tetap inline dan sederhana untuk dijelaskan di semua pengguna.

+1 Kami mengalami situasi di mana file tulis kami memiliki referensi ke volume jauh yang telah dikonfigurasi sebelumnya. Tulis otomatis menambahkan nama proyek ke nama volume tersebut yang kemudian gagal dipasang karena nama yang tidak cocok. Mampu menyetel nama proyek secara eksplisit dalam file compose yml akan membuat konvensi penamaan jauh lebih jelas bagi orang lain yang terlibat dalam proyek daripada menyembunyikan variabel lingkungan dalam file eksternal tidak jelas yang mungkin berbeda di seluruh lingkungan.

@edevenport dalam kasus Anda, Anda dapat menggunakan opsi eksternal dari nama volume:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

Terima kasih @fesor - Saya seharusnya menjelaskan lebih detail. Saya sebenarnya memasang volume glusterfs menggunakan konfigurasi yang mirip dengan ini:

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

Dalam hal ini, media menjadi projectname_media pada host dan gagal untuk me-mount kecuali volume glusterfs dibuat sebelumnya dengan nama proyek. Saya telah berpikir untuk memasang volume glusterfs pada host secara manual dan menggunakan external dalam file docker-compose, tetapi saya lebih suka tidak melakukannya secara manual di semua node sebelumnya.

@edevenport Saya mengerti itu. Tapi Anda bisa menambahkan volume ini secara manual dengan docker volume create dan menggunakannya:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

Jadi tidak perlu mengubah proyek, dan menyingkirkan awalan apa pun.

Kasus @timgriffiths adalah sesuatu yang lebih kompleks, dan tidak ada solusi lain. Saya menggunakan pembungkus sederhana sekitar docker-compose hanya untuk tidak mengingat nama proyek.

@fesor jadi kami telah mengatasi masalah ini dengan hanya menempelkan file tulis dalam nama folder deskriptif, ini mengatasi batasan ini. Tetapi akan sangat menyenangkan melihatnya ditambahkan di rilis selanjutnya

@timgriffiths Saya membuat PR (https://github.com/docker/compose/pull/3118) - mungkin ini akan membantu. Tetapi itu tidak menangani kasus Anda jika Anda memiliki banyak file penulisan.

@fesor bahwa PR akan sempurna apakah ada kemungkinan untuk menggabungkannya?

Sekarang Compose menyediakan file Environment , sehingga nama proyek dapat disimpan di sana.

@mkuzmin menyedihkan bahwa ada COMPOSE_FILE tetapi tidak ada COMPOSE_OVERRIDE_FILE .

@fesor AFAIK Anda dapat menentukan banyak file

@ schmunk42 Saya juga dapat menentukan nama proyek. Tapi ini tidak menyelesaikan masalah. Saya ingin menerapkan skrip seperti ini:

docker-compose up -d

dari pada

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME dalam contoh di atas ditentukan oleh CI. Dan fitur seperti .env file itu keren tapi ... tidak berguna jika nama proyek tetap ada.

Saya menggunakan .env untuk variabel DRY env (dan untuk docker-compose <1.7 saya memiliki pembungkus sederhana), tetapi itu tidak menyelesaikan masalah lain. @timgriffiths sudah menunjuk kasus dengan penerapan di swarm cluster.

COMPOSE_FILE=one.yml:two.yml adalah cara mengatur banyak file. Jadi cukup sertakan file timpa di $COMPOSE_FILE

@dnephin ketinggalan fitur itu, keren.

Nah ... tentang penyebaran swarm, saya sudah menangani itu melalui COMPOSE_PROJECT_NAME dalam variabel ENV pekerjaan jenkin saya jadi masalah hanya dengan penerapan manual. Dan implementasi saya tidak mengizinkan nama proyek default diganti jadi ...

Masalah ini sudah hampir 2 tahun dan masih belum terselesaikan. Saya bertanya-tanya apa sebenarnya yang menghalangi tim buruh pelabuhan untuk akhirnya menambahkan perbaikan yang tepat. Apakah benar-benar sulit menambahkan petunjuk konfigurasi baru yang sederhana untuk docker-compose.yml file?

Meskipun solusi dengan .env bagus, itu tidak selalu dapat digunakan (file .env mungkin sudah digunakan oleh aplikasi Anda). Dan itu juga masih ada solusi.

Dan saya bahkan telah melihat masalah baru lainnya yang mungkin terkait dengan nama proyek merayap ke versi terbaru (# 3966).

Jadi apa masalahnya sebenarnya?

Apakah benar-benar sulit menambahkan petunjuk konfigurasi baru yang sederhana untuk docker-compose.yml file?

Tidak! Persoalannya tidak pernah sulit dalam implementasinya.

Meskipun solusi dengan .env bagus, itu tidak selalu dapat digunakan (file .env mungkin sudah digunakan oleh aplikasi Anda). Dan itu juga masih ada solusi.

Ini bukan solusi, ini solusi! File .env berisi variabel lingkungan yang akan dibaca oleh Tulis. Jika Anda memiliki variabel lingkungan yang akan dibaca oleh aplikasi Anda, letakkan di file yang berbeda (katakanlah app.env ) dan referensikan menggunakan opsi env_file .

Jadi apa masalahnya sebenarnya?

Menambahkan nama proyek ke file docker-compose.yml membuatnya kurang portabel, yang bukan merupakan sesuatu yang ingin kami dorong. Sekarang ada cara (dengan .env ) untuk terus-menerus menetapkan nama proyek tanpa mengorbankan portabilitas docker-compose.yml , kasus untuk menambahkannya sebagai opsi konfigurasi lebih lemah. Itulah alasan utama masalah ini tidak berpindah.

Menambahkan nama proyek ke file docker-compose.yml membuatnya kurang portabel,

Bukankah ini opsional? Secara pribadi saya tidak pernah memeriksa docker-compose.yml tetapi hanya menyediakan docker-compose-example.yml di repo saya yang saya sesuaikan secara lokal. Misalnya selama pengembangan, saya dapat menambahkan beberapa env vars tambahan atau memetakan volume tambahan ke dalam penampung saya. Mengapa tidak juga memberi kami opsi untuk menentukan nama proyek?

Mengikuti argumentasi Anda, Anda juga harus memindahkan semua network options ke .env karena mereka biasanya tidak portabel sama sekali dan bergantung pada pengaturan jaringan mesin host Anda.

Dengan kata lain: Apa yang membuat nama proyek begitu istimewa? Sudah ada banyak opsi lain di docker-compose.yml yang tidak terlalu portabel. Mengapa tidak memberi pengembang opsi untuk memilih apa pun yang terbaik untuk kasus penggunaannya?

Saya juga berpikir opsi harus tersedia. Saat penggunaan Docker menjadi lebih luas, proyek dengan hanya satu pengembang yang menggunakan containerization dalam alur kerjanya akan menjadi lebih umum. Dalam kasus penggunaan tersebut, nama proyek menjadi konstan tidak masalah. Contoh bagus dari proyek lain yang memungkinkan fleksibilitas seperti ini adalah gelandangan dengan Vagrantfile . Mereka menyadari bahwa ada kasus penggunaan untuk tim besar tetapi kemudian juga mengenali skenario pengembang serigala tunggal.

Saya pikir menerapkan opsi nama proyek di sini penting untuk diadopsi. Ini bisa membuat pengembang tunggal tidak peduli dengan "strategi konfigurasi nama proyek yang dapat diskalakan".

Menambahkan nama proyek ke file docker-compose.yml membuatnya kurang portabel, yang bukan sesuatu yang ingin kami dorong. Sekarang ada cara (dengan .env) untuk terus-menerus menetapkan nama proyek tanpa mengorbankan portabilitas docker-compose.yml, kasus untuk menambahkannya sebagai opsi konfigurasi lebih lemah. Itulah alasan utama masalah ini tidak berpindah.

Bagaimana menambahkan nama proyek ke docker-compose.yml membuatnya kurang portabel?

IMHO justru sebaliknya, seperti yang ditunjukkan oleh # 3966 yang dibuat oleh @mikehaertl. Masalah ini dengan jelas menunjukkan bahwa tidak memiliki nama proyek yang disimpan di docker-compose.yml membuat segala sesuatunya menjadi kurang portabel (seperti: memiliki kemungkinan lebih besar untuk berbenturan dengan proyek penulisan lain yang dimulai dari mesin yang sama) karena Compose bergantung pada konvensi tentang nama folder kontainer yang tidak diketahui oleh banyak orang, setidaknya pada awalnya.

Menambahkan file .env tidak hanya menambahkan hal tambahan untuk dipelajari bagi orang baru yang ingin mengadopsi Tulis tetapi karena saya juga harus menambahkannya ke repo saya di sebelah docker-compose.yml untuk mencegahnya tabrakan Saya tidak melihat bagaimana hal itu akan menjadi portabilitas yang berbeda dari hanya mendefinisikan nama proyek di docker-compose.yml .

Saya juga menambahkan nama ke dalam docker-compose.yml. File .env digunakan dalam kerangka kerja lain yang saya gunakan dan yang penting tetap di luar repo. Namun, untuk memelihara container yang dilokalkan di seluruh developer saya, semakin sedikit mereka mengetahui tentang buruh pelabuhan (pada awalnya) semakin baik. Saya ingin titik masuk sederhana yang tidak akan bertabrakan dengan proyek lain. Saya tidak ingin menjelaskan mengapa segala sesuatunya seperti itu. Sederhana saja

klon repo
buruh pelabuhan-menulis

Solusi saya sekarang adalah membuat file yang diusulkan @ schmunk42 .

Penampung itu sendiri seharusnya tidak peduli dengan nama proyek. Mengapa menggunakan variabel lingkungan sebagai mekanisme yang hanya ditujukan bagi tuan rumah untuk diperhatikan?

Saya ingin melihat dukungan untuk ini pada file docker-compose.yml . Jika seseorang perlu mengaturnya melalui variabel lingkungan, itu dapat didefinisikan dalam file .env (jika tidak diatur secara langsung pada host) dan digunakan melalui substitusi variabel dalam file docker-compose.yml .

Jika penampung bernama diizinkan, mengapa proyek bernama tidak diizinkan?

Kasus penggunaan di mana definisi nama proyek dalam file .yml akan berguna adalah sebagai berikut:
Kami memiliki file pembuat galangan yang sama untuk server web yang berbeda (kredensial basis data yang berbeda, volume data yang berbeda, beberapa perbedaan kecil seperti logo, dll). Ada 3 layanan per aplikasi yang berjalan, dan mereka dikonfigurasi dalam file tulis. Ketika beberapa server dijalankan berdampingan, alangkah baiknya melihat layanan mana yang termasuk dalam proyek mana.

Substitusi variabel dalam nama penampung berguna, dengan $ COMPOSE_PROJECT_NAME sebagai awalan. Saya memahami solusi file .env, tetapi ini membuatnya tidak lebih "ramah-pengembang" dalam lingkungan penerapan (CI).

Memiliki satu container kill-compose-docker dari docker-compose yang sama sekali berbeda karena tidak ada -p atau kumpulan variabel lingkungan dan Anda membuat docker-compose dalam subfolder "buruh pelabuhan" adalah bug kritis menurut pendapat saya.

Ada terlalu banyak ruang untuk kesalahan dalam penerapan yang serius. Lupakan untuk menentukan nama proyek, apakah dalam -p, .env atau di tempat lain: Anda akan offline untuk beberapa waktu sampai Anda menyadari apa yang terjadi. Lebih buruk lagi: layanan yang bertabrakan menjadi offline, bukan yang sedang Anda kerjakan. Anda akan memiliki hari yang bahagia :(

@dnephin Apa sebenarnya yang menahan tim buruh pelabuhan untuk akhirnya menerapkan ini? Berapa banyak lagi pengguna yang mengeluh dibutuhkan? Ini adalah perbaikan yang sepele sehingga sulit dipercaya, bahwa masih belum ada yang terjadi.

Mungkin saya satu-satunya di sini yang memiliki kekhawatiran dengan ini, tetapi bagaimanapun juga.
Dalam pengaturan kami, kami hanya memodifikasi file .env dan app.env untuk berpindah lingkungan, tetapi ini bergantung pada memiliki banyak file dan menggabungkan file yml .

Jika ini diterapkan, harap pikirkan tentang BC.

Misalnya. jika nama proyek ditentukan dalam docker-compose.yml dan .env yang terakhir harus diutamakan. Jika tidak, orang yang mengandalkan pengelolaan ini melalui .env , mendapatkan masalah serupa dengan tumpukan yang tumpang tindih, seperti dengan alur kerja saat ini dan mengandalkan nama folder.

@ schmunk42 Kami tidak mengatakan, bahwa fitur .env harus dihilangkan. Jika Anda lebih suka memiliki nama proyek Anda di .env maka cukup jangan konfigurasikan di docker-compose.yml .

Tetapi yang lain lebih suka memilikinya di docker-compose.yml seperti yang ditunjukkan dengan jelas oleh diskusi di sini. Mereka harus bisa melakukannya, jika mereka mau. Ini adalah fitur opsional. Apa yang diutamakan jika keduanya dikonfigurasi adalah masalah penentuan konvensi sederhana.

Srsly, tambahkan proyek bernama. Kasus penggunaan:
Proyek satu:
docker-compose up --build --remove-orphans

• nginx
• konten statis
  Proyek dua:
  docker-compose up --build --remove-orphans
• nginx
• konten statis

Ketika proyek dua dimulai itu membunuh proyek satu kontainer dengan keluar 137 (kode 128 + level 9).

Sekarang saya harus menjalankan docker system prune dan membangun kembali jaringan setiap hari agar saya tidak memiliki lusinan kontainer mati.

export COMPOSE_PROJECT_NAME=somethingnew

Dapatkah seseorang dari tim inti akhirnya menjelaskan, apa yang menahan fitur ini? Sungguh membuat frustrasi, bagaimana hal-hal yang begitu mudah diperbaiki diblokir tanpa alasan yang jelas.

Satu-satunya argumen sejauh ini adalah mempertahankan portabel docker-compose.yml . Ini tidak masuk akal, karena

• nama proyek di file komposer tidak otomatis membuatnya tidak portabel lagi
• bahkan tidak semua orang memiliki persyaratan ini
  
  
  
  • kami sudah memiliki opsi lain yang dapat membatasi portabilitas dengan cara yang sama: networks , port , ...
  
  

Itu semua sangat tergantung pada kasus penggunaan tertentu. Tetapi hanya karena beberapa tidak menginginkan opsi ini tidak berarti bahwa setiap orang harus mengikuti pendapat mereka!

@mikehaertl Anda sudah memiliki nama proyek yang tetap. Letakkan saja .env file dan tetapkan variabel COMPOSE_PROJECT_NAME sana. Saya tidak melihat manfaat apa pun dalam nama proyek di file tulis lagi.

@fesor Saya biasanya tidak memiliki file .env bawah kontrol versi karena berisi pengaturan khusus mesin / lingkungan - itu juga mengapa saya ingin melihat nama proyek dapat dikonfigurasi dalam file docker-compose.yml .

@fesor : Saya pikir @thasmo benar dalam hal ini. Nama proyek harus memiliki opsi untuk ditentukan dalam file compose.yml karena jika relevan dengan semua pengembang yang menggunakan proyek, itu harus dalam kontrol versi.

@fesor Maaf, tapi menurut saya preferensi pribadi bukanlah argumen yang nyata. Pertanyaan sebenarnya bukanlah, mengapa kita tidak ingin menggunakan .env atau variabel lingkungan. Ini sebaliknya: Mengapa itu tidak dimasukkan ke dalam file konfigurasi di tempatnya?

Hampir semua opsi yang dapat Anda berikan ke docker pada baris perintah dapat ditentukan dalam file itu. Hanya nama proyek yang dikecualikan untuk beberapa alasan misterius. Apakah ini bentuk apartheid di antara argumen? : PI mengklaim hak yang sama untuk semuanya! Biarkan pengembang memutuskan dan jangan memberikan batasan buatan pada mereka.

Dan lagi: Tidak ada yang mengambil opsi lama dari Anda - kami akhirnya hanya menginginkan opsi tambahan ini. Itu adil.

@dnephin : Sepertinya Anda dan semua orang senang dengan solusi yang dinyatakan dalam perbaikan cr7pt0gr4ph7 untuk masalah ini .

Apakah Anda bersedia menerima permintaan pull yang mengimplementasikannya, atau apakah Anda bermaksud meminta salah satu pengelola menulisnya?

@bayu_joo

@dnephin @fesor yang memiliki nama proyek di * compose.yml memfasilitasi skema konfigurasi terpadu

Tidak jelas bagi saya mengapa nama proyek itu penting. Tidak ada bagian dari file konfigurasi yang bergantung pada nama proyek tertentu.

Satu-satunya kualitas penting dari nama proyek adalah bahwa nama itu tidak bertentangan dengan nama proyek lain, yang sebenarnya merupakan argumen untuk tidak memasukkannya ke dalam file docker-compose.yml . Pengembang suatu proyek akan sering menggunakan nama direktori yang berbeda untuk setiap proyek, jadi defaultnya sering kali benar untuk sebagian besar kasus penggunaan.

Jika default tidak benar, ada cara bagi pengembang untuk menimpanya ( -p , atau COMPOSE_PROJECT_NAME ), yang bisa berupa alias atau dimasukkan ke dalam file .env .

Saya tidak menentang file proyek yang akan menentukan nama proyek, saya hanya ingin memahami mengapa fitur ini sangat penting bagi sebagian orang. Jika itu karena file Tulis memerlukan nama proyek tertentu, saya melihat itu sebagai masalah terpisah yang harus ditangani secara berbeda,

Saya ingin memiliki 4 file compose dalam 1 direktori. Nama direktori salah secara default di sini. Satu-satunya pilihan yang saya miliki adalah .env yang hanya berfungsi untuk 1 file tulis dalam 1 direktori.

_Mengapa saya mengesampingkan COMPOSE_PROJECT_NAME dan -p: _
COMPOSE_PROJECT_NAME dan -p menurut saya tidak disimpan dalam produksi karena Anda harus ingat untuk menyetelnya. Atau buat skrip startup dan ingat untuk tidak menggunakan docker compose secara langsung. Ketika Orang A mengandalkan mekanisme ini dan Orang B tidak mengetahuinya, itu adalah kegagalan tertentu.
(Saya sudah merinci di atas)

@dnephin Bagi saya dan tim saya, logika aplikasi biasanya disimpan dalam folder htdocs di folder proyek kami. Ini memungkinkan kita untuk menyimpan dokumen / sumber terkait lainnya bersama-sama dalam satu direktori. Sebagai seorang pengembang yang bekerja dengan pengembang jarak jauh. Mudah bagi saya untuk meminta mereka mengadopsi Docker jika saya tidak perlu berasumsi apa pun tentang struktur folder mereka. Saya telah menyatakan ini di masa lalu, .env bukanlah pilihan bagi saya karena biasanya bukan bagian dari repo yang kita semua bagikan.

Tidak jelas bagi saya mengapa nama proyek itu penting. Tidak ada bagian dari file konfigurasi yang bergantung pada nama proyek tertentu.

Itu terjadi lebih dari sekali pada saya, bahwa saya melakukan 'docker-compose down' pada host - dan memiliki kontainer yang berbeda turun dari yang saya inginkan! Hanya karena saya tidak ingat, bahwa ada juga konfigurasi di file .env .

Satu-satunya kualitas penting dari nama proyek adalah tidak bertentangan dengan nama proyek lain, yang sebenarnya merupakan argumen untuk tidak memasukkannya ke dalam file docker-compose.yml. Pengembang suatu proyek akan sering menggunakan nama direktori yang berbeda untuk setiap proyek, jadi defaultnya sering kali benar untuk sebagian besar kasus penggunaan.

Mungkin itu benar untuk Anda - ini bukan untuk saya dan banyak orang lainnya. Struktur aplikasi saya seperti myapp/app/docker-compose.yml . Jadi semua aplikasi saya berbagi nama direktori app . Dan saya memiliki lebih dari 1 kontainer pada satu host.

Jika default tidak benar, ada cara bagi pengembang untuk menimpanya (-p, atau COMPOSE_PROJECT_NAME), yang bisa berupa alias atau dimasukkan ke dalam file .env.

Sungguh, aku mulai merasa seperti berada di novel Kafka di sini. Bukankah sudah jelas, bahwa pada dasarnya Anda dapat meletakkan semua opsi baris perintah untuk docker menjadi docker-compose.yml - kecuali untuk satu pengecualian besar ini?

Alih-alih bertanya berulang kali dan mengabaikan jawaban kami, mengapa tidak ada orang yang akhirnya tidak bisa membenarkan penolakan tersebut. Dan tidak: "... tapi saya tidak membutuhkannya" bukanlah argumen yang valid!

@dnephin Saya memiliki banyak proyek dalam repo git mereka sendiri dan untuk menjaga direktori root project tetap bersih, saya meletakkan semua hal yang berhubungan dengan buruh pelabuhan ke subfolder bernama docker (membangun konteks hanya menjadi .. , semuanya bekerja dengan indah).

Untuk menjalankan beberapa proyek di satu server, saat ini saya harus membuat docker/.env.dist di setiap repo dan cp docker/.env.dist docker/.env setelah git clone . Jika tidak, nama proyek hanya docker , yang jelas tidak saya inginkan. Dalam beberapa kasus .env berisi kata sandi dll, jadi menyalin .env.dist tetap diperlukan, tetapi dalam kebanyakan kasus .env ada hanya karena tidak ada cara untuk mendefinisikan COMPOSE_PROJECT_NAME di docker-compose.yml .

Saya memahami bahwa mungkin ada kesalahan dalam cara wadah dimulai dan dihentikan jika COMPOSE_PROJECT_NAME sama digunakan dua kali di dalam docker-compose.yml , tetapi itu sudah terjadi jika saya lupa menyalin .env.dist atau ketika saya tidak sengaja menetapkan nama yang sama di dua file .env yang berbeda di server yang sama. Bagi saya, akan ideal jika saya dapat menentukan default_compose_project_name tepat di docker-compose.yml dan kemudian menimpa nilai dalam .env jika, katakanlah saya ingin menjalankan salinan pementasan dari beberapa proyek . Ini akan menjadi 100% SM, tetapi lebih nyaman.

Saya telah menyatakan ini di masa lalu, .env bukanlah pilihan bagi saya karena biasanya bukan bagian dari repo yang kita semua bagikan.

Mungkin, itulah akar penyebab semuanya, saya katakan sebelumnya bahwa docker-compose "membajak" file ini dan kami terpaksa mengganti nama barang kami menjadi app.env .

Mungkin docker-compose.env adalah pilihan yang tepat.

FWIW: Kami hanya mengubah file .env dalam produksi, file yml digabungkan dengan docker-compose.override.yml jika diperlukan.

Solusinya juga dengan mendefinisikan file yml Anda dengan cara yang tidak dimulai tanpa file .env , mis. menggunakan variabel image: $IMAGE .

Ini adalah solusi untuk 4 file docker- compose saya dalam 1 kasus direktori di atas @ schmunk42 ? Betulkah?

@RobIsHere Tapi Anda tetap harus menggunakan -f , bukan?

Sebagai balasan untuk @dnephin dalam komentar ini:

Tidak jelas bagi saya mengapa nama proyek itu penting.

Ini penting karena ini mempengaruhi nama kontainer Docker yang dikelola docker-compose . Jika Anda lupa menyetel nama proyek, docker-compose ps tidak akan menemukan wadah yang Anda buat sebelumnya dengan docker-compose --project-name <project_name> up -d <container_name> .

Selain itu, ketika Anda menjalankan perintah global docker ps , nama proyek akan dimasukkan ke dalam daftar kontainer yang sedang berjalan, sehingga Anda tahu dari mana asalnya. Misalnya, jika Anda menguji beberapa proyek kode sekaligus yang semuanya menggunakan MySQL, dan masing-masing memiliki container mysql , maka docker ps akan menampilkan daftar container yang ambigu. Jadi, nama proyek penting dalam konteks banyak proyek Docker yang berjalan di mesin yang sama.

Tidak ada bagian dari file konfigurasi yang bergantung pada nama proyek tertentu.

Harus menetapkan nama proyek di tempat yang berbeda dari _setiap variabel lain yang terkait dengan proyek Docker Compose_ tidak masuk akal.

Satu-satunya kualitas penting dari nama proyek adalah tidak bertentangan dengan nama proyek lain, yang sebenarnya merupakan argumen untuk tidak memasukkannya ke dalam file docker-compose.yml.

Untuk alasan yang dinyatakan dalam paragraf pertama saya, ini bukan _ "satu-satunya kualitas penting dari nama proyek" _. Ini untuk kemudahan penggunaan dan pemahaman.

Pengembang suatu proyek akan sering menggunakan nama direktori yang berbeda untuk setiap proyek, jadi defaultnya sering kali benar untuk sebagian besar kasus penggunaan.

Dalam kasus non-default di mana pengembang meletakkan _all_ file Docker terkait di direktori docker , yang merupakan cara yang masuk akal untuk mengatur proyek Docker, keajaiban yang menetapkan nama proyek akan membuat nama proyek yang bertentangan. Jadi konflik yang sama yang Anda sebutkan terjadi dalam kasus khusus ini. Anda tidak perlu melindungi pengembang dari benturan nama proyek saat mereka secara eksplisit menetapkan nama proyek.

Jika default tidak benar, ada cara bagi pengembang untuk menimpanya (-p, atau COMPOSE_PROJECT_NAME), yang bisa berupa alias atau dimasukkan ke dalam file .env.

Menyetel variabel lingkungan adalah tingkat kerumitan tambahan yang tidak diperlukan. Saat Anda berbagi proyek antara pengembang dengan kontrol versi, masuk akal untuk menggunakan hanya file. Harus menyertakan parameter baris perintah dengan setiap pemanggilan itu membosankan dan rawan kesalahan. Dan file .env tidak dapat dibagikan di kontrol versi karena seharusnya berisi variabel _user-specific_, bukan _project-specific_. Oleh karena itu, cara saat ini untuk menetapkan nama proyek tidak cukup.

Saya tidak menentang file proyek yang akan menentukan nama proyek, saya hanya ingin memahami mengapa fitur ini sangat penting bagi sebagian orang. Jika itu karena file Tulis memerlukan nama proyek tertentu, saya melihat itu sebagai masalah terpisah yang harus ditangani secara berbeda,

Semua variabel yang mempengaruhi fungsi docker-compose harus ditempatkan di tempat yang sama, file docker-compose.yml . Cara pengaturan nama proyek saat ini memperkenalkan kerumitan yang tidak perlu.

Hampir semua orang yang berlangganan masalah ini setuju dengan poin-poin ini.

Menambahkan kemampuan untuk menyetel nama proyek di docker-config.yml bahkan tidak akan bertentangan dengan fungsionalitas saat ini. Tidak ada alasan untuk tidak menerapkannya.

@ schmunk42 Terakhir kali saya memeriksa, buruh pelabuhan tidak mengizinkan kami untuk memilih nama file .env kami. Apakah saya melewatkan sesuatu (sulit untuk mengikuti perubahan). Mengubahnya menjadi sesuatu seperti docker-compse.env akan memperbaikinya untuk kasus penggunaan saya. Masalah yang saya miliki adalah saya menggunakan dua teknologi yang sangat populer yang keduanya membutuhkan file .env. Kerangka PHP Laravel tidak melacak file itu di repositori dan di lingkungan produksi terkadang tidak ada.

Saya menemukan ini menjadi hambatan nyata ketika pertama kali mengadopsi Docker karena seperti @RobIsHere menggambarkan. Semua direktori proyek saya dalam format myapp/htdocs/docker-compose.yml . Pada hari-hari awal mengadopsi Docker, saya tidak sengaja menghapus kontainer lain yang tidak saya inginkan. Akan lebih baik jika buruh pelabuhan menamai proyek itu secara acak daripada menggunakan nama folder dalam kasus saya.

Saya memiliki beberapa pengembang jarak jauh lainnya yang mulai mengadopsi Docker. Sebagai sebuah tim, selalu lebih mudah bagi saya untuk menginstruksikan para pengembang ini untuk selalu / hanya docker-compose up untuk menjalankan aplikasi ini. Semakin sedikit pengadopsi awal ini yang tahu tentang Docker, semakin baik. Begitu mereka melihat kekuatan di baliknya, mereka akan mengambilnya sendiri.

Jadi untuk meringkas, kasus penggunaan tampaknya menjadi saat default tidak sesuai. Sudah ada cara untuk mengganti default, tetapi cara tersebut mungkin rawan kesalahan dan tidak jelas bagi pengguna awal.

Kasus-kasus di mana default tidak sesuai adalah:

• beberapa file tulis dalam direktori yang sama (sudah mengharuskan Anda menentukan -f untuk menjalankannya)
• menggunakan nama direktori yang sama untuk semua proyek (saya rasa ini juga mengharuskan Anda untuk menentukan -f , solusi yang mungkin adalah dengan menggunakan nama direktori yang unik).

@dnephin Saya akan menambahkan, satu lagi kemungkinan batu sandungan bagi pengguna awal Docker.

@dnephin Anda juga memiliki masalah ini dalam komentar ini:

Awalnya saya ingin nama di docker-compose.yml, tetapi setelah memikirkannya lebih lanjut, saya sangat menyukai ide file terpisah. File terpisah memberi Anda opsi untuk tetap tidak mengontrol versi jika Anda mau (untuk kasus di mana Anda ingin setiap pengguna dapat memiliki nama proyek yang berbeda).

Menetapkan urutan prioritas resolusi nama proyek seperti ini akan menyelesaikan masalah itu (angka yang lebih besar menggantikan angka yang lebih kecil):

1. docker-compose.yml
2. Variabel lingkungan COMPOSE_PROJECT_NAME
3. Opsi baris perintah --project-name

Terakhir kali saya memeriksa, buruh pelabuhan tidak mengizinkan kami untuk memilih nama file .env kami.

@fiveanddone AFAIK Anda tidak dapat melakukan itu, tetapi itu juga hanya akan memindahkan masalah, karena Anda kemudian harus tahu file ENV mana yang Anda perlukan untuk proyek tersebut.

Dalam kasus kami dengan phd5 , kami memindahkan (app) -environment ke src/ dan .env semata-mata adalah "control-environment-file", saya mencoba menjelaskannya di sini .
Saya tidak suka ini dan tidak akan mengubahnya sendiri. Saya tahu bahwa ini mungkin tidak dapat dilakukan untuk banyak proyek.
Tetapi memiliki .env dari aplikasi Anda pada level yang sama dengan docker-compose.yml menjadi sangat menjengkelkan, karena a) Anda mendapatkan variabel dalam "lingkungan kontrol" yang tidak termasuk di sana dan b) Anda harus meneruskan variabel ini ke penampung Anda, jika Anda membutuhkannya di sana dan c) Anda tidak dapat mengganti / mengubahnya lagi di file app.env .

@dnephin Bagaimana memperkenalkan docker-compose.env sebagai file env yang disukai dan menggunakan .env sebagai pengganti. Anda melakukan hal yang sama dengan fig.yml sekali.

Saya tidak berpikir itu memperbaiki masalah untuk semua orang. Penamaan file .env terasa seperti masalah yang berbeda bagi saya.

Saya pikir inti dari masalahnya adalah ini:

Desain asli dari docker-compose up adalah menjadi satu perintah (singkat) yang dapat Anda jalankan untuk menjalankan layanan. Inilah yang diharapkan pengembang darinya. Namun perilaku tersebut tidak dapat dicapai untuk beberapa pengguna (dalam kasus ini ).

Ada banyak cara untuk mengatasi masalah tersebut, tetapi tidak ada yang tampaknya berhasil untuk semua orang.

Saya pikir urutan prioritas (dari tertinggi ke terendah) harus seperti ini:

1. --project-name (selalu diganti)
2. COMPOSE_PROJECT_NAME variabel lingkungan
3. Default yang ditentukan oleh pengguna, terpisah dari file berversi apa pun
4. Default yang ditentukan oleh proyek, yang dapat diperiksa
5. Nama direktori (default ketika tidak ada yang ditentukan)

(3) dapat dicapai dengan file .docker/project-name (seperti yang diusulkan dalam OP)
(4) dapat dicapai dengan bidang di file docker-compose.yml

Sangat disayangkan bahwa perlu ada banyak cara berbeda untuk menetapkan nama proyek.

@dnephin tentang 3, membiarkan pengguna mengatur default, untuk itulah env vars, tidak perlu membuat file

Hmm ... Dan bagaimana jika kita menggeneralisasikan masalah sedikit dan hanya memperkenalkan default_environment bagian dalam docker-compose.yml ? Dengan cara ini kita akan dapat menyetel COMPOSE_PROJECT_NAME tanpa memasukkan bidang khusus di yaml, tetapi juga dapat menentukan variabel default lainnya, yang mungkin ada di tempat lain di seluruh file. Ini akan mengurangi jumlah kasus ketika .env.dist perlu disalin menjadi .env dan biaya untuk lupa melakukannya akan lebih sedikit.

Contoh penggunaan:

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

Yaml ini sangat mirip dengan yang sering saya miliki - yaml ini menggambarkan sketsa vis, yang selalu memiliki layanan bernama web , tetapi juga dapat dicadangkan oleh server API mini dan mungkin wadah dengan database. Diasumsikan bahwa https://github.com/jwilder/nginx-proxy berada di depan segalanya dan mendengarkan port nyata 80 dan 443.

Saat ini, tidak peduli apakah saya menggunakan mesin lokal atau server jarak jauh, saya harus ingat untuk mempertahankan .env dan juga untuk memastikan bahwa variabel lingkungan _all_ disetel di sana. Jika, katakanlah, saya lupa SUBDOMAIN , kontainer dimulai, tetapi server web tetap rusak.

Dengan default_environment bagian yang saya miliki, saya dapat memiliki semua variabel produksi saya di tempat dalam satu file dan saya tidak perlu menyalin .env.dist saat berada di server. Pada mesin lokal, dalam contoh di atas saya hanya akan menempatkan satu variabel ke .env , yang akan menjadi ROOT_HOST=example.com.dev (atau mungkin saya bahkan bisa export ROOT_HOST=example.com.dev di profil bash? )

Untuk meringkas, default_environment bagian docker-compose.yml tidak hanya dapat memecahkan masalah yang sedang kita diskusikan, tetapi juga dapat mengaktifkan beberapa trik tambahan yang bagus, sementara 100% BC dan mudah dipahami!

WDYT?

Kedengarannya bagus, ini mungkin berguna bagi saya dalam beberapa skenario.

Namun, ketahuilah bahwa mengingat diskusi (panas) di atas, file
solusi secara kasar diterjemahkan menjadi ini: “Daripada menambahkan file baru ke
yml, bagaimana kalau kita menambahkan bagian baru? ” :)

Pada Sel, 28 Feb 2017, 00:02 Alexander Kachkaev [email protected]
menulis:

Hmm ... Dan bagaimana jika kita sedikit menggeneralisasi masalah dan hanya memperkenalkan
default_env di docker-compose.yml. Dengan cara ini kami mendefinisikan
COMPOSE_PROJECT_NAME tanpa memperkenalkan bidang khusus di yaml, tapi
juga dapat menentukan variabel default lainnya, yang kemungkinan besar adalah
hadir di tempat lain di seluruh file. Ini akan mengurangi jumlah kasus
kapan .env.dist perlu disalin ke .env dan biaya lupa ke
melakukannya akan lebih sedikit.

Contoh penggunaan:

~ / projects / sketches / sketch-42 / docker / docker-compose.yml

versi: "2"
default_env:
SUBDOMAIN = sketsa-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = sketsa-42
jasa:
web:
membangun:
konteks: ../
dockerfile: docker / Dockerfile
lingkungan Hidup:
- VIRTUAL_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- VIRTUAL_PORT = 80
- VIRTUAL_NETWORK = proxy
- LETSENCRYPT_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
restart: selalu
jaringan:
- proxy

jaringan:
proxy:
luar:
nama: proxy

Yaml ini sangat mirip dengan apa yang sering saya miliki - yaml ini menggambarkan sebuah vis
sketch, yang selalu memiliki layanan bernama web, tetapi juga dapat di-backup
oleh server API mini dan mungkin wadah dengan database. Diasumsikan
yang https://github.com/jwilder/nginx-proxy berada di depan dan mendengarkan
ke port nyata 80 dan 443.

Saat ini, tidak peduli apakah saya menggunakan komputer lokal atau server jarak jauh,
Saya harus ingat untuk memelihara .env dan juga untuk memastikan itu semua
variabel lingkungan diatur di sana. Jika, katakanlah, saya lupa
SUBDOMAIN, penampung dimulai, tetapi server web tetap rusak.

Dengan bagian default_env yang saya miliki, saya dapat memiliki semua produksi saya
variabel di tempat dan saya tidak perlu menyalin .env.dist di server.
Di mesin lokal, saya hanya akan memasukkan satu variabel ke .env, yaitu
ROOT_HOST = example.com.dev (atau mungkin saya bahkan bisa mengekspor
ROOT_HOST = example.com.dev di profil bash?)

Untuk meringkas, bagian default_env di docker-compose.yml tidak hanya bisa
memecahkan masalah yang kita diskusikan sekarang, tetapi juga dapat mengaktifkan beberapa penggunaan yang lebih bagus
skenario!

WDYT?

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/745#issuecomment-282885661 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
.

Memiliki "project_name" di dalam docker-compose.yml akan menyelesaikan masalah dengan tumpukan kami.
Kami memiliki repo monolit dengan pohon standar yang menangani banyak proyek, yang terlihat kurang lebih seperti ini:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

Ini jelas lebih kompleks daripada di dunia nyata, jadi kita tidak bisa hanya memindahkan file docker-compose.yml ke folder "projectA / projectB".

Kami memiliki CLI di root yang menanyakan proyek mana yang akan di-boot, dan karena nama proyek bergantung langsung pada folder induk dari docker_compose.yml, kami menghadapi konflik.

Karena kita tidak menulis sendiri perintah docker-compose (dibungkus di dalam skrip CLI kita), kita tidak bisa begitu saja menambahkan arg "-p" ke perintah secara manual.
Solusi bagi kami adalah selalu menghasilkan nama_proyek di dalam skrip CLI sehingga kami selalu memiliki "-p" saat memanggil docker-compose, berdasarkan absolute_path, tetapi kedengarannya aneh.

Beberapa orang di sini mengatakan "ini berfungsi sebagian besar waktu karena sebagian besar proyek, docker-compose.yml terletak di dalam folder root proyek, dan proyek memiliki nama yang berbeda, menghindari konflik", saya tidak bisa setuju ini. Itu tidak selalu di dalam folder root.

Mengapa ini memungkinkan untuk menentukan "container_name" dalam file docker-compose.yml (menonaktifkan penskalaan) untuk layanan, tetapi tidak dapat menentukan "project_name" untuk file docker-compose.yml itu sendiri, pada level yang sama dengan "versi" / "layanan" / "jaringan" / "volume"?

Ini tampaknya perlu dengan penggunaan scale sehingga nama kontainer jelas. (mis. <project_name>_<container_name>_1 ).

Ini akan membantu saat menggunakan nama wadah untuk dns.

Datang ke sini berharap ini dilakukan. Meninggalkan kecewa. 3 tahun +

Ya itu salah satu masalah kegunaan yang paling bodoh dari Docker dan tidak diperbaiki.

Kami menghabiskan begitu banyak waktu untuk berdebat dengan pengembang tentang hal itu, dan meskipun ada konsensus, tidak ada pengakuan bahwa ini adalah desain yang buruk.

Ini membuat frustrasi karena ada dukungan pengguna yang jelas untuk ini, tetapi karena tidak sesuai dengan kasus penggunaan pengembang sendiri - kami dibiarkan mengulangi tahun ini demi tahun.

Apa gunanya docker-compose jika kita perlu menambahkan opsi menggunakan cli?
Saya memiliki beberapa wadah yang ditimpa berkat skema penamaan.

Hari ini saya sedang menyiapkan proyek docker-compose lagi dengan file .env untuk memberi proyek nama yang tetap. Jadi saya pikir saya memeriksa masalah ini karena sudah beberapa tahun sejak terakhir kali saya memeriksanya. Tapi tidak ada yang baru di sini sejauh yang saya bisa lihat? Saya rasa saya harus tetap menggunakan solusi .env . Bagi saya, menamai proyek di file yaml sepertinya hal paling dasar yang dapat Anda lakukan, tetapi saya kira ada sesuatu tentang ini yang tidak saya mengerti karena belum diselesaikan.

Harus menentukan nama proyek eksternal (oleh baris perintah atau variabel), tetapi tidak mampu mengaturnya dalam docker-compose.yml berkas - berkas yang menentukan benar-benar segala sesuatu yang lain - hanya ceroboh. Ada banyak kasus di mana suatu proses mungkin perlu menangani tumpukan layanan tertentu berdasarkan file docker-compose.yml sewenang-wenang terlepas dari nama direktori induk, lingkungan shell, atau keberadaan baris tertentu dalam .env file. Saya tidak ingin pekerjaan CI saya harus terus-menerus "mencari tahu" apa nama proyek yang seharusnya - itu harus dinyatakan dengan jelas dalam docker-compose.yml sehingga pekerjaan saya dapat mengekstraknya dan menggunakannya.

Ini tampaknya terjadi berkali-kali dengan proyek ini. Docker adalah teknologi yang luar biasa tetapi terkadang saya bertanya-tanya apakah para pengembang benar-benar memiliki pengalaman dunia nyata, atau apakah mereka semua hanya peretas berusia 18 tahun yang merasa paling tahu? Orang ingin menggunakan barang ini untuk pekerjaan nyata, tidak menghabiskan waktu mereka terus-menerus mencari solusi.

Dugaan saya adalah bahwa tim sementara mengabaikan masalah ini. Mencoba untuk meyakinkan pengembang buruh pelabuhan bisa sangat merepotkan untuk membuatnya lebih ringan.

Argumen yang jelas dilawan dengan beberapa logika aneh yang tidak masuk akal. Pendapat pengguna dunia nyata bahwa semua datang ke sini karena alasan yang sama diabaikan. Memalukan.

Saya tidak ingin pekerjaan CI saya harus terus-menerus "mencari tahu" apa nama proyek yang seharusnya - itu harus dinyatakan dengan jelas di docker-compose.yml sehingga pekerjaan saya dapat mengekstrak dan menggunakannya.

Apakah Anda memiliki masalah bahwa tumpukan Anda dinamai seperti "build1234" dan / atau bagaimana Anda ingin menggunakan nama tumpukan di tempat lain, seperti docker exec build1234_myservice script.sh ?

Mungkin tidak cocok dengan kasus penggunaan apa pun, tetapi karena dikatakan ...

Dalam pengaturan kami, kami hanya mengubah .env file saat menyiapkan proyek (klon). Jika kita membutuhkan perubahan atau konfigurasi dinamis, kita menggunakan kembali variabel dari .env di docker-compose.yml . Keuntungannya adalah bahwa buruh pelabuhan-menulis memperingatkan Anda (atau gagal) jika variabel hilang.

Saya tidak ingin memberi tahu Anda bahwa Anda harus mengubah alur kerja Anda, karena saya juga merasa terganggu dengan masalah ini.
Ini pada dasarnya seperti, kami memperlakukan perubahan ke docker-compose.yml lebih seperti perubahan pada kode sumber, sementara .env hanyalah konfigurasi. Tetapi saya juga setuju bahwa ada beberapa opsi di docker-compose.yml , seperti network yang sangat bergantung pada proyek. Kembali ke atas; Saya akan mendefinisikan variabel .env untuk jaringan. 🤐

Saya tidak ingin memberi tahu Anda bahwa Anda harus mengubah alur kerja Anda, karena saya juga merasa terganggu dengan masalah ini.

Saya memikirkan tentang situasi saya sendiri lagi. Saya sebenarnya tidak memiliki masalah dengan pengaturan eksternal nama proyek, dan sebenarnya saya melakukan ini dengan bendera -p <project_name> , yang memungkinkan untuk mengisolasi contoh unik dari tumpukan di CI dan menjalankan beberapa tumpukan secara bersamaan jika perlu. Hanya rantai CI yang perlu mengetahui nama proyek itu sehingga dapat dibuat secara otomatis atau acak (tetapi diketahui), tidak masalah. Saya juga tidak memiliki masalah dengan menggunakan variabel lingkungan untuk mengganti nama default, namun saya menemukan trik .env tidak jelas.

Namun ada situasi lain yang berguna untuk menetapkan _default name_ proyek secara eksplisit di suatu tempat. Jadi mengapa mengambil nama direktori induk sebagai sumber dari nama ini? Itu, bagi saya, adalah titik lemah di sini. Ini bisa diambil dari mana saja - pilihan direktori induk sepertinya sewenang-wenang dan tanpa banyak alasan (misalnya di hampir semua proyek saya, file docker-compose.yml berada di subdirektori bernama docker ). Jadi jika itu akan sewenang-wenang, simpan di tempat yang lebih eksplisit, seperti file yml, daripada membuat efek samping eksternal dengan mempengaruhi nama direktori induk yang dalam banyak kasus harus sepenuhnya independen dari konten direktori (berdasarkan tahun pengalaman bekerja dengan sumber daya yang dapat digunakan kembali).

Itu bisa diambil dari mana saja - pilihan direktori induk sepertinya sewenang-wenang dan tanpa banyak alasan (misalnya di hampir semua proyek saya, file docker-compose.yml berada di subdirektori yang disebut docker).

Jika Anda membutuhkan sesuatu selain ID acak, maka saya tidak melihat alternatif nyata untuk direktori induk. Setidaknya Anda memiliki kesempatan untuk mengetahui dari mana tumpukan Anda "berasal".
Tetapi saya juga setuju dengan Anda, karena dalam proyek kami, kami telah menguji tumpukan folder tests yang - tanpa file .env - juga akan bertabrakan dengan buruk satu sama lain. Itulah mengapa saya mengusulkan untuk memilih file bernama docker-compose.env yang akan menjadi IMHO lebih jelas.

Apakah kalian akan menutup bug ini dengan mengakui bahwa Anda tidak peduli, atau menerapkan hal yang sangat sederhana yang diinginkan sebagian besar dari kita? Itu 2,86 tahun kemudian. Turun dari pot. Kuasai keputusan Anda atau perbaiki kesalahan Anda. Bagaimanapun Anda ingin melihatnya. Lakukan lebih dari tidak sama sekali.

@matsaman dan semua orang mengacungkan jempolnya:

Apakah kalian akan menutup bug ini dengan mengakui bahwa Anda tidak peduli, atau menerapkan hal yang sangat sederhana yang diinginkan sebagian besar dari kita? Itu 2,86 tahun kemudian. Turun dari pot. Kuasai keputusan Anda atau perbaiki kesalahan Anda. Bagaimanapun Anda ingin melihatnya. Lakukan lebih dari tidak sama sekali.

Siapa "kalian"? Dalam open source, komunitas memiliki keputusan dan memperbaiki kesalahan orang lain. Docker adalah open source. Pertimbangkan untuk mengirimkan permintaan tarik daripada merengek.

Saya juga sedih karena ini belum dilaksanakan. Tapi, dalam open source kami berkontribusi, atau menunggu dengan sabar.

CLI arg:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Gagal.

File env:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Gagal.

Solusi yang diusulkan dengan nama proyek dalam file yml:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

Yay!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

HAI/

Siapa "kalian"?

@benjaminwood Ini adalah pengelola proyek ini. Argumen Anda akan masuk akal jika kita berbicara tentang perubahan yang kompleks dan tidak ada yang punya waktu untuk melakukannya.

Hal ini cukup jelas tidak terjadi di sini: Penerapannya mungkin akan sangat mudah bagi mereka yang terbiasa dengan basis kode dan jauh lebih sulit bagi seseorang dari luar. Jadi bukan karena tidak ada yang punya waktu untuk melakukannya, tetapi pengelola tidak mau melakukannya. Dan inilah yang sangat menarik bagi para pendukung di sini, mengingat sejak lama masalah ini terbuka sekarang dan massa: +1: di sini.

Solusi yang diposting berulang kali di sini semuanya terkenal tetapi tidak berlaku untuk semua orang. Dan saya masih tidak dapat menemukan jawaban mengapa hampir semua hal hanya nama proyek yang ditinggalkan di fitur docker-compose.yml . Jika seseorang berpikir, itu bukan miliknya di sana maka jangan gunakan! Tapi jangan menghalangi opini Anda pada orang lain jika tuntutannya sangat jelas.

Mari kita lihat dari sudut lain.

Jika saya berada dalam folder dengan file docker-compose.yml , bagaimana cara mengetahui Nama Proyek yang dimiliki tumpukan saya?
Itu pertanyaan yang cukup mendasar, tetapi tidak ada jawaban yang mudah untuk itu.

Saat ini (diurutkan berdasarkan prioritas):

• nilai -p
• nilai COMPOSE_PROJECT_NAME dari lingkungan Anda
• nilai COMPOSE_PROJECT_NAME dari file .env
• nama direktori saat ini

Untuk menjadi pendukung iblis, mengapa menambahkan yang kelima ke pengaturan yang sudah membingungkan ini?

Terlepas dari keputusan itu, harus ada info "dry-runnable" tentang nama saat ini. Tidak ada docker-compose config memilikinya, atau docker-compose ps jika tumpukan tidak berjalan.
Mungkin docker-compose create adalah opsi terbaik yang tersedia saat ini, tetapi jauh dari sempurna.

Setidaknya harus ada sesuatu seperti docker-compose config --project-name . Saat ini saya perlu mengetahui lokasi di atas dan memeriksanya dalam urutan yang benar.

Jika saya berada dalam folder dengan file docker-compose.yml, bagaimana cara mengetahui Nama Proyek yang dimiliki stack saya?

Sekali lagi: Jika Anda tidak ingin menggunakannya, jangan gunakan! Jika Anda senang dengan solusi Anda - bagus untuk Anda !! Tidak ada yang akan berubah untuk Anda, jadi Anda tidak akan bingung sama sekali!

Tapi tidak bisakah Anda menerima bahwa persyaratan lain memiliki berbeda? Yang kami inginkan hanyalah bagian yang hilang secara logis ini akhirnya ditambahkan.

Untuk menjadi pendukung iblis, mengapa menambahkan yang kelima ke pengaturan yang sudah membingungkan ini?

Satu-satunya alasan mengapa ini membingungkan adalah karena nama proyek ditinggalkan docker-compose.yml di tempat pertama. Yang lain, semuanya akan ada di file itu sekarang. Kami dapat menentukan daftar prioritas - bukan masalah.

Saat ini saya perlu mengetahui lokasi di atas dan memeriksanya dalam urutan yang benar.

Mengapa Anda tidak tahu nama buruh pelabuhan dari proyek Anda dan mengapa itu relevan bagi Anda? Dan mengapa Anda tidak menggunakan mekanisme yang sama di semua proyek Anda jika itu sangat membingungkan Anda?

Sekali lagi: Jika Anda tidak ingin menggunakannya, jangan gunakan! Jika Anda senang dengan solusi Anda - bagus untuk Anda !! Tidak ada yang akan berubah untuk Anda, jadi Anda tidak akan bingung sama sekali!

Pertanyaan saya bukan tentang menggunakan fitur baru, tetapi kurangnya fitur yang sudah ada. Nama proyek adalah satu-satunya informasi relevan yang digunakan docker-compose untuk memulai dan menghentikan kumpulan kontainer tertentu.
Orang-orang di utas ini mengeluh tentang mematikan kontainer yang salah, karena nama proyek bukan bagian dari tumpukan.

Tapi tidak bisakah Anda menerima bahwa persyaratan lain memiliki berbeda? Yang kami inginkan hanyalah bagian yang hilang secara logis ini akhirnya ditambahkan.

Jika Anda menambahkan ini, orang-orang akan mengeluh tentang mematikan kontainer yang salah, karena itu adalah bagian dari tumpukan, karena telah menggunakan nama direktori sebelumnya.

Satu-satunya alasan mengapa ini membingungkan adalah karena nama proyek tidak dimasukkan ke dalam docker-compose.yml sejak awal. Yang lain, semuanya akan ada di file itu sekarang. Kami dapat menentukan daftar prioritas - bukan masalah.

Sebenarnya Anda tidak dapat menambahkan ini dengan cara BC, karena itu harus memiliki prioritas yang lebih rendah sebagai nama direktori, yang akan membuatnya tidak berguna. Itu sebabnya saya bertanya "bagaimana mendapatkan nama-proyek".

Mengapa Anda tidak tahu nama buruh pelabuhan dari proyek Anda dan mengapa itu relevan bagi Anda?

Karena saya biasanya menggunakan nama direktori, tetapi terkadang nilai khusus di .env - ini relevan karena nama proyek menentukan wadah tempat tindakan dijalankan.

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

Ini akan mematikan tumpukan pertama Anda, akan sama dengan nama proyek di file yml .

Dan mengapa Anda tidak menggunakan mekanisme yang sama di semua proyek Anda jika itu sangat membingungkan Anda?

Ya, saya hanya menggunakan fitur default docker-compose ; sebagian besar waktu nama direktori baik-baik saja, tetapi jika saya perlu mengganti namanya, tetapi ingin terus bekerja dengan kumpulan wadah yang sama saya menambahkan file .env .

Jika Anda menambahkan ini, orang-orang akan mengeluh tentang mematikan kontainer yang salah, karena itu adalah bagian dari tumpukan, karena telah menggunakan nama direktori sebelumnya.

Itu tidak masuk akal. Jika seseorang tidak menambahkan nama proyek ke docker-compose.yml tidak akan ada yang berubah. Dan jika mereka menambahkannya maka itu karena mereka menginginkannya di sana! Tidak ada yang akan menambahkannya kecuali mereka membutuhkannya.

Dan bahkan jika mereka melakukannya, semuanya baik-baik saja. Saya tidak mengerti masalah mana yang Anda coba buat di sini. Anda terlalu rumit.

Jika Anda mencampur semua opsi di mana nama proyek dapat dikonfigurasi, maka menurut saya ini adalah masalah Anda. Anda tidak boleh melakukan itu sama sekali.

3 dari 4 opsi di pohon prioritas tidak berguna setelah Anda memiliki beberapa file tulis bernama dalam sebuah direktori. Jangan beri tahu saya untuk membuat subdirektori, karena saya masih membagikan file .env di dalamnya.

Jangan beri tahu saya untuk membuat subdirektori, karena saya masih membagikan file .env di dalamnya.

Apakah Anda berbagi file .env khusus aplikasi yang digunakan di env_file ?
Atau yang digunakan docker-compose ?
Atau apakah Anda mencampurnya?

Itu tidak masuk akal. Jika seseorang tidak menambahkan nama proyek ke docker-compose.yml tidak akan ada yang berubah.

Bukan itu masalahnya, tetapi ketika akan ditambahkan perilaku berubah drastis.

Saat kita menyalin tumpukan ke direktori baru untuk menghasilkan instance sementara (mis. Untuk menguji peningkatan), kita tidak perlu menyentuh docker-compose.yml sama sekali. Tetapi jika ini adalah bagian dari tumpukan, kita perlu memutuskan apakah kita menimpanya dengan .env atau apakah kita mengubahnya menjadi docker-compose.yml .

Ya, mungkin itu seharusnya tidak ditambahkan sejak awal, tetapi memiliki opsi lain di sini juga tidak membuat segalanya lebih mudah dan lebih ringkas.

Saya memiliki satu file .env umum yang digunakan 4 file bernama compose (dalam direktori yang sama). Tidak ada variabel lingkungan. Tidak ada skrip shell. Saya menggunakan hanya menulis.

Saya lebih suka ini

docker-compose -f service1.yml up -d

Sebaliknya lebih seperti ini

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42 Anda benar-benar yakin bahwa ini adalah solusi untuk mengetik 'COMPOSE_PROJECT_NAME = ...' setiap kali untuk setiap perintah tulis-galangan, mungkin selain nama file tulis? Itu juga mengharuskan Anda untuk mengetahui dan mengingat nama proyek. Mampu menentukan nama proyek dalam variabel lingkungan memiliki kegunaannya pasti tetapi dalam beberapa kasus Anda hanya ingin memiliki direktori dengan beberapa file yml di dalamnya dan dapat dengan mudah mengelola proyek dengan cara yang sangat mudah tanpa harus ingat nama proyek yang Anda pilih beberapa bulan lalu dan tanpa harus mengingat untuk mengekspor variabel lingkungan.

Tidak bisakah Anda menggunakan satu folder per layanan dan masih memiliki file .env di folder teratas?

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

Cukup tulis nama proyek ke dalam file (-path) 😉

Saya menyerah. Jelas basis pelanggan untuk ini telah berubah.

Beri tahu saya apa yang salah dengan proposal yang saya buat untuk Anda.

Saya memiliki masalah yang sama pada awalnya, tetapi kami telah menyesuaikan alur kerja kami dengan fitur yang tersedia.

Saya tidak dapat mengingat secara tidak sengaja membunuh tumpukan dalam 2 tahun terakhir, oleh tidak seorang pun dari tim kami. Kami menjalankan> 200 tumpukan dengan sekitar 1.000 kontainer dan 1.000 pemindahan otomatis atau manual dengan cara ini.

Saya tidak benar-benar ingin terlibat di sini ... tetapi saya tidak bisa menahan.

Ada perbedaan yang sangat penting antara "solusi" dengan keadaan saat ini, dan solusi "tepat" dengan kemungkinan yang ada. Apa yang harus difokuskan pada masalah ini adalah menemukan solusi yang "tepat", yang menurut saya cukup jelas, meskipun beberapa mungkin masih tidak setuju.

@schunk42 & @ikehal

Saya tidak dapat mengingat secara tidak sengaja membunuh tumpukan dalam 2 tahun terakhir, oleh tidak seorang pun dari tim kami .

Aku harus bertanya Saya melihat bahwa Anda berdua adalah bagian dari organisasi codemix . Apakah Anda rekan kerja? Mulai bertanya-tanya apakah di balik layar kalian berdua adalah orang bodoh.

Saat ini (diurutkan berdasarkan prioritas):

1. nilai -p
2. nilai COMPOSE_PROJECT_NAME dari lingkungan Anda
3. nilai COMPOSE_PROJECT_NAME dari file .env Anda
4. nama direktori saat ini

Untuk menjadi pendukung iblis, mengapa menambahkan yang kelima ke pengaturan yang sudah membingungkan ini?

Masalah yang saya lihat adalah _setiap nilai_ yang saat ini tersedia untuk digunakan adalah _environment-specific_. Tidak ada cara untuk memberikan opsi khusus proyek.

1 + 2. Harus disediakan secara manual oleh pengguna yang menjalankan perintah.

1. _Bisa_ dibagikan, tetapi dalam praktiknya .env harus diabaikan dan tidak dibagikan untuk alasan yang baik. (Saya mengatasi ini dengan membagikan .env.example , tetapi ini masih membutuhkan langkah manual tambahan.)
2. Secara efektif acak, dan khusus pengguna / lingkungan. (Saya juga melihat ini sebagai fallback, karena compose _needs_ nama proyek. Ini bahkan bukan fallback yang sangat bagus, karena mungkin ada proyek di direktori berbeda dengan nama yang sama yang akan bentrok.)

Menurut pendapat saya, dan banyak dari mereka yang ada di utas ini, harus ada opsi yang hidup antara 3 dan 4, di mana nama proyek default _can_ disediakan di file apa pun yang digunakan untuk membuat galangan kapal untuk proyek ini dan digunakan sebagai yang pertama fallback. Nilai ini kemudian akan dibagikan oleh siapa pun yang menerapkan proyek ini. Opsi 1-3 akan menggantikan nilai itu, dan opsi 4 hanya akan digunakan jika tidak tersedia.

@benjaminwood Saya dapat meyakinkan Anda bahwa tidak ada yang menertawakan masalah ini. Ya, kami mengenal satu sama lain selama beberapa waktu dan ini bukan pertama kalinya kami sangat tidak setuju. Saya mungkin terdengar menjengkelkan bagi beberapa pengguna di sini, tetapi itu bukan niat saya. Sebenarnya saya ingin berbagi pengalaman saya dan mengusulkan solusi. Saya percaya bahwa saya memiliki pengalaman yang luas tentang topik ini. Jika fitur tersebut diperkenalkan seperti yang diusulkan, itu akan memperkenalkan sumber besar kemungkinan kesalahan dalam pengaturan kami.

@joshuajbour

1. Bisa dibagikan, tetapi dalam praktiknya .env harus diabaikan dan tidak dibagikan untuk alasan yang baik.

Itu tergantung pada penyiapan Anda, kami telah mengabaikannya di semua repositori proyek kami.
Namun kami tidak mengabaikannya di repositori staging dan production stack-only kami. Jika Anda ingin membagikan nama yang dikomit dalam docker-compose.yml Anda juga dapat menggunakan .env (file ini hanya untuk perintah docker-compose - tidak ada yang lain)

1. Secara efektif acak, dan khusus pengguna / lingkungan.

Ini tidak lebih atau kurang acak dari nilai dalam docker-compose.yml , Anda perlu melihat konfigurasi tumpukan sebagai folder, bukan satu file. Jika Anda melakukannya, Anda dapat memiliki nama di .env atau nama subfolder.

Saya punya satu alternatif terakhir untuk Anda semua:

docker stack deploy -c docker-compose.yml the-project-name

(*) Hanya tersedia dalam mode swarm

Saya tidak dapat melihat bagaimana nama proyek dapat ditempatkan ke dalam file yml di masa mendatang, itu akan sangat bertentangan dengan gagasan definisi tumpukan.

Terima kasih @ schmunk42. Saya percaya Anda dan saya pikir Anda telah menangani banyak hal dengan cukup baik di antara semua pendapat kuat yang ditampilkan di utas ini.

itu akan memperkenalkan sumber besar kemungkinan kesalahan dalam penyiapan kami.

Ada intinya. Tutup masalahnya.

Itu tergantung pada penyiapan Anda, kami telah mengabaikannya di semua repositori proyek kami. Namun kami tidak mengabaikannya di repositori staging dan production stack-only kami.

Jadi fitur ini yang diinginkan semua orang tidak boleh diperkenalkan karena akan merusak arsitektur repositori Anda yang tidak biasa?

Jika Anda ingin membagikan nama yang dikomit dalam docker-compose.yml Anda juga dapat mengkomit .env (file ini hanya untuk perintah docker-compose - tidak ada yang lain).

Nah, jika satu-satunya hal di file .env adalah COMPOSE_PROJECT_NAME , maka ya. Tapi itu diisi dengan banyak variabel _secure_ lain yang tidak ingin saya lakukan. Dan saya mengimpornya ke docker-compose menggunakan properti environment . Untuk inilah biasanya file .env ...

Saya masih benar-benar tidak mengerti bagaimana ini akan merusak pengaturan Anda, karena dalam proposal saya itu hanya menimpa nama proyek default yang diambil dari direktori. Dan jika Anda bergantung pada itu (karena ini adalah direktori yang dikomit _into_ repo Anda sebagai lawan dari direktori tempat repo Anda digandakan), lalu bagaimana itu bisa ditimpa oleh pengaturan docker-compose.yml (karena itu juga dikomit ke repo Anda; Anda mengontrol kedua hal dalam skenario Anda)?

@ schmunk42 Apa yang Anda katakan adalah "Saya tidak menginginkan fitur baru, karena selain itu saya tidak memahami penyiapan proyek saya lagi".

Sungguh? Ini adalah argumen Anda mengapa Anda ingin semua orang yang membutuhkan ini melakukannya tanpa?

Sekadar catatan: Aku juga di sini. Jangan ragu untuk menutup masalah ini. Diskusi di sini menjadi sia-sia.

Jadi fitur ini yang diinginkan semua orang tidak boleh diperkenalkan karena akan merusak arsitektur repositori Anda yang tidak biasa?

Saya menyuarakan keprihatinan saya bahwa hal itu mungkin menimbulkan sumber kesalahan tambahan.

Nah, jika satu-satunya hal di file .env saya adalah COMPOSE_PROJECT_NAME, maka ya. Tapi itu diisi dengan banyak variabel aman lainnya yang tidak ingin saya lakukan. Dan saya mengimpornya ke docker-compose menggunakan properti environment.

Gunakan secrets.env untuk itu dan impor melalui env_file .
Bagaimana pengaruhnya terhadap alur kerja Anda?

Untuk inilah file .env biasanya ...

Benar ... tapi saya masih berpikir masalahnya adalah docker-compose membajak file .env .

Bagaimana jadinya, jika Anda dapat menyetel variabel ini ditambah docker-compose.yml , seperti IMAGE_VERSION , dalam file bernama docker-compose.env ?

Saya tidak pernah berani mengusulkan COMPOSE_COMMAND_ENV_FILENAME=.env - sampai sekarang :)

Saya masih benar-benar tidak mengerti bagaimana ini akan merusak pengaturan Anda, ...

Memang benar itu tidak langsung rusak, tetapi ini hanya tentang poin pertama saya - dan memperkenalkan lebih banyak opsi.

Pikirkan tentang menggunakan banyak file -f docker-compose.A.yml -f docker-compose.B.yml , katakanlah A adalah proyek Anda dan bergantung pada nama proyek berdasarkan direktori (kami melakukannya, karena kami mengontrolnya!), Sedangkan B adalah a set layanan tambahan dengan project_name: extra , secara tidak sengaja diperkenalkan saat pengujian di folder yang memiliki file .env yang menimpa nama proyek dengan COMPOSE_PROJECT_NAME=testing .

Tetapi sekarang proyek apa pun, yang dimulai tanpa file .env , akan dinamai extra . 💥

Kami menggabungkan file di lebih dari beberapa level, termasuk beberapa file *.env , ini kasus penggunaan yang sangat valid.

Sungguh? Ini adalah argumen Anda mengapa Anda ingin semua orang yang membutuhkan ini melakukannya tanpa?

Peringatan: Sedikit Di Luar Topik, tapi masih terkait buruh pelabuhan ...

• "Menurutku kita tidak benar-benar membutuhkannya"
• "memiliki lebih banyak lapisan daripada yang diperlukan. lebih banyak kerumitan"

@mikehaertl Saya benar-benar bertanya-tanya apakah Anda melihatnya seperti ini;)

Hai semuanya,

Kami telah mengambil diskusi penuh gairah di utas ini (terima kasih kepada Anda yang menjaganya tetap sopan dan ramah!) Dan sementara kami pada dasarnya masih percaya bahwa nama proyek tidak termasuk dalam file Tulis, kami berhasil menemukan apa kami yakin akan menjadi jalan tengah yang wajar dengan PR berikut: # 5378. Karena itu, kami sangat menghargai masukan Anda tentang hal ini untuk memastikannya menjawab kebutuhan Anda.

Inilah intinya:

• Anda dapat menambahkan entri x-project-name di dalam file Tulis Anda. Kunci ini diabaikan secara default.
• Saat COMPOSE_X_PROJECT_NAME disetel di lingkungan Anda (atau .env file), Compose akan mencoba mengambil nama proyek dari entri x-project-name di dalam file Tulis Anda.
• Opsi ini memiliki prioritas yang lebih rendah dari COMPOSE_PROJECT_NAME dan --project-name

Dengan senang hati menjawab pertanyaan atau masalah apa pun terkait hal ini.

@ shin- Jadi COMPOSE_X_PROJECT_NAME harus disetel ke 1 untuk mengaktifkan fitur ini?

Jika demikian, COMPOSE_ENABLE_X_PROJECT_NAME mungkin juga merupakan nama yang perlu dipikirkan, tetapi ini hanya 2 sen saya - toh saya tidak akan menggunakannya 😄

@ schmunk42 Semua nilai "truth-y" akan berhasil , tapi ya, itulah idenya.

@matsaman Cool, terima kasih atas masukan yang berguna dan dapat ditindaklanjuti.

Daripada Anda memberi tahu kami bahwa kami harus memberi tahu pengguna akhir untuk menyetel variabel atau memanggil param, Anda memberi tahu kami bahwa kami harus memberi tahu pengguna akhir untuk menyetel variabel atau memanggil parameter.

Sejujurnya, & benar-benar tidak sia-sia, saya tidak dapat membayangkan bagaimana Anda menganggap ini sebagai solusi dengan cara apa pun.

@ shin- Saya akan menjelaskan bagaimana perubahan ini tidak membuat perbedaan yang berguna:

Harus menyetel variabel lingkungan untuk mengaktifkan pencarian nama proyek di file tulis kira-kira sama dengan {jumlah pekerjaan, risiko lupa, dan kenyamanan}, seperti menyetel variabel lingkungan untuk nama proyek itu sendiri.

Inti dari pengaturan nama proyek dalam file tulis adalah untuk menghindari penggunaan variabel lingkungan. Anda dapat menggunakan variabel lingkungan nama proyek yang diutamakan untuk memberi pengguna opsi untuk mengganti nama proyek dalam file tulis.

Saya pikir ini adalah solusi yang sangat baik, karena tidak akan merusak BC dan akan menghindari kesalahan selama penggabungan seperti yang saya jelaskan di atas.

Harus menyetel variabel lingkungan untuk mengaktifkan pencarian nama proyek di file tulis kira-kira sama dengan {jumlah pekerjaan, risiko lupa, dan kenyamanan}, seperti menyetel variabel lingkungan untuk nama proyek itu sendiri.

Tidak, Anda dapat melakukan pengaturan ini sekali, secara global di lingkungan Anda - Anda tidak perlu melakukan ini di setiap proyek.

Tidak, Anda dapat melakukan pengaturan ini sekali, secara global di lingkungan Anda - Anda tidak perlu melakukan ini di setiap proyek.

Saya berasumsi yang Anda maksud secara global di semua cangkang yang Anda tanam di komputer Anda. Jika Anda melakukan itu, maka Anda bisa mendapatkan perilaku yang tidak diinginkan dalam proyek yang sama sekali tidak terkait. Ini juga akan menyebabkan kebingungan saat pengembang menarik proyek dari kontrol versi dan lupa menyetel variabel lingkungan.

Salah satu tujuan terpenting dari memiliki nama proyek di file tulis adalah untuk memastikan setiap variabel yang berkaitan dengan proyek penulisan disimpan di kontrol versi.

@nhooey @matsaman
Ini secara khusus ditujukan untuk membantu orang-orang yang memiliki banyak file penulisan dalam direktori yang sama, yang tidak dapat memilih solusi file .env . Jika ini harus selalu aktif untuk proyek Anda, mudah untuk mengaturnya di file .env , .profile , atau di mana pun yang akan memastikan x-project-name akan selalu diambil memperhitungkan.

Daripada Anda memberi tahu kami bahwa kami harus memberi tahu pengguna akhir untuk menyetel variabel atau memanggil param, Anda memberi tahu kami bahwa kami harus memberi tahu pengguna akhir untuk menyetel variabel atau memanggil parameter.

Perhatian utama kami dengan hal ini selalu bahwa "pengguna akhir" memiliki proyeknya sendiri dan ingin menghindari konflik nama dengan cara apa pun. Dalam hal ini, mereka harus mengontrol nama proyek, bukan distributornya. Jika Anda mengirimkan proyek "turnkey" ke pelanggan, sama mudahnya untuk menetapkan COMPOSE_X_PROJECT_NAME dalam file .env - jadi saya bingung jujur ​​bagian mana dari ini yang menjadi perhatian.

Jika Anda melakukan itu, maka Anda bisa mendapatkan perilaku yang tidak diinginkan dalam proyek yang sama sekali tidak terkait.

Bisakah Anda memberi contoh? Saya tidak dapat memikirkan perilaku yang tidak diinginkan hanya dengan menyetel COMPOSE_X_PROJECT_NAME di shell saya.

Salah satu tujuan terpenting dari memiliki nama proyek di file tulis adalah untuk memastikan setiap variabel yang berkaitan dengan proyek penulisan disimpan di kontrol versi.

Mengapa Anda tidak bisa menggunakan .env untuk itu? Tidak ada yang melarang menyimpan .env dalam kontrol versi (ya, ini tidak umum).

Kami memiliki .env pada awalnya. Anda jelas melewatkan seluruh percakapan.

@matsaman Anda benar-benar perlu mengurangi sikap Anda. Anda telah bersikap jahat sejak Anda mulai berkomentar di utas ini dan hasilnya tidak ada apa pun selain memperburuk percakapan. Jika Anda tidak bisa bersikap sopan saat berbagi pemikiran, kami dapat melakukannya tanpa pendapat Anda.

Untuk memperjelas beberapa kebingungan

Anda sudah bisa melakukannya

Sebelumnya Anda dapat menetapkan nama proyek menggunakan variabel lingkungan. Variabel lingkungan baru bukanlah sebuah nama, ini adalah tombol yang mengaktifkan fitur yang memungkinkan Anda menyetel nama proyek di file tulis.

Saya berasumsi yang Anda maksud secara global di semua cangkang yang Anda tanam di komputer Anda. Jika Anda melakukan itu, maka Anda bisa mendapatkan perilaku yang tidak diinginkan dalam proyek yang sama sekali tidak terkait.

Jika yang Anda maksud adalah "proyek lain" as-in, "sesuatu yang tidak tersusun dapat membaca ini dan memutuskan" Saya pikir itu tidak realistis. Ada banyak variabel lingkungan yang disetel di setiap shell. Variabel lingkungan diberi spasi dengan benar sebagai "COMPOSE_X_".

Jika yang Anda maksud adalah "proyek tulis lainnya" maka saya pikir Anda sebenarnya membuat argumen mengapa variabel ini diperlukan. Jika fitur tersebut diaktifkan secara default, siapa pun yang mengandalkan perilaku default saat ini akan rusak.

Jika tidak satu pun dari itu, harap klarifikasi.

Ini juga akan menyebabkan kebingungan saat pengembang menarik proyek dari kontrol versi dan lupa menyetel variabel lingkungan.

Jika sebuah proyek hanya bekerja dengan nama proyek tertentu maka saya pikir ada masalah lain. Tidak boleh ada kasus di mana proyek hanya bekerja dengan satu nama.

Saya melihat ini sebagai argumen lain untuk tidak memasukkan nama proyek di file Tulis. Jika nama proyek ada dalam file tulis, maka dua proyek mana pun dapat menggunakan nama yang sama, menyebabkan konflik, yang akan merusak kedua proyek. Nama harus benar-benar ditetapkan oleh pengembang yang mengetahui nama proyek lain apa yang sudah digunakan.

Sayangnya ini tidak akan membantu saya karena alasan yang telah saya sebutkan lebih dari setahun yang lalu.

Solusi yang melibatkan variabel lingkungan akan membutuhkan pengguna yang perlu mengetahui cara membuatnya. Saya tahu bahwa ini mungkin tampak sulit dipercaya, tetapi tidak semua orang bekerja di dalam terminal. Sekali lagi, menempatkan .env di repositori bukanlah pilihan bagi saya.

Keindahan dari buruh pelabuhan adalah up . Bukan instruksi tentang cara menyiapkan panggilan itu.

@tokopedia

Sekali lagi, menempatkan .env di repositori bukanlah pilihan bagi saya.

Bisakah Anda mengembangkannya? Saya benar-benar mendengar Anda tentang pengguna dengan pengetahuan teknis yang lebih rendah, tetapi jika mereka tidak dimaksudkan untuk berinteraksi dengan kode atau lingkungan, mengapa menyertakan file .env dengan proyek itu menjadi masalah?

@ shin- Ya, tidak masalah.

Saya dalam beberapa kasus menyertakan file itu di repositori tetapi tidak berfungsi sepanjang waktu. Kasus penggunaan saya sebagian besar melibatkan pengembangan web di mana pengetahuan teknis pengembang dapat sangat bervariasi.

Parameter .env rumah yang digunakan dalam kerangka lain. Beberapa variabel di dalam .env adalah kredensial untuk layanan luar seperti SMTP. Sebagian besar pengembang di tim saya mengarahkan layanan tersebut ke titik akhir mereka sendiri menggunakan file .env mereka sendiri. Jika .env tidak ada, saya memiliki default.

Untuk pengembang yang kurang teknis yang mungkin hanya ingin mengubah beberapa CSS, aplikasi berfungsi dengan baik tanpa file .env . Itu dengan asumsi mereka tidak memberi nama setiap folder proyek yang sama. :)

Ini mungkin tidak terlihat banyak tetapi ketika Anda bekerja dengan banyak pengembang dan desainer yang menjangkau negara - semakin sederhana semakin baik.

Docker telah membuat hidup saya jauh lebih mudah dan saya sangat berterima kasih atas proyek ini, tetapi saya dapat merasakan frustrasi di sekitar utas ini.

@fiveanddone Terima kasih atas wawasannya! Jadi jika file .env bernama docker-compose.env (atau yang serupa), apakah hal itu akan meredakan kekhawatiran Anda?

@ shin-

Ya, itu untuk kasus penggunaan saya.

Apakah file env dimuat secara otomatis oleh Docker Compose?

Jika tidak, dapatkah docker-compose.env dimuat secara otomatis?

@nhooey Berkas env dimuat secara otomatis jika diberi nama .env . Dan Anda juga dapat menentukan file env untuk setiap layanan satu per satu. Lihat dokumen .

File env dimuat secara otomatis jika bernama .env. Dan Anda juga dapat menentukan file env untuk setiap layanan satu per satu. Lihat dokumen.

Bukan untuk menjadi pelit di sini, tapi itu tidak benar. Dan IMHO sumber kesalahpahaman terbesar dari seluruh topik.

Tidak ada variabel .env yang diteruskan ke wadah / layanan, jika Anda tidak meneruskannya secara eksplisit , dengan menggunakan salah satu

env_file: 
  - .env

atau

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

File .env dimuat secara otomatis, ya, tetapi tanpa konfigurasi lebih lanjut ini hanya berlaku untuk variabel lingkungan Compose CLI ini .

Saya sangat mendukung penggantian nama itu menjadi docker-compose.env secara default dan bahkan lebih baik - variabel untuk itu , jadi ini dapat digunakan dengan cara BC hanya dengan menyetel satu ENV-var.

(terima kasih kepada Anda yang menjaganya tetap sopan dan sopan!)

Saya mendengar Anda dan saya pasti bersalah karena tidak selalu menjaga ketenangan saya. Maaf untuk itu. Beberapa komentar terkadang benar-benar membantu saya memulai ... akan mengatasinya.

Jika nama proyek ada dalam file tulis, maka dua proyek mana pun dapat menggunakan nama yang sama, menyebabkan konflik, yang akan merusak kedua proyek.

Perhatian utama kami dengan hal ini selalu bahwa "pengguna akhir" memiliki proyeknya sendiri dan ingin menghindari konflik nama dengan cara apa pun. Dalam hal ini, mereka harus mengontrol nama proyek, bukan distributornya.

@ shin- Ini terdengar seperti yang umumnya disepakati, bahwa docker-compose.yml selalu menjadi bagian dari sebuah proyek dan tinggal di gudang proyek. Menurut saya, itu tidak sepenuhnya benar. Beberapa dari kita tidak membagikan docker-compose.yml tetapi ingin mempertahankan versi lokalnya dengan penyesuaian lokal (mis. Pengaturan pengembangan, uji coba, dll.).

Dan mengenai "hindari konflik nama": Alih-alih konflik nama dengan nama proyek, kami sekarang memiliki cara (IMO) konflik nama yang lebih kritis pada tingkat sistem berkas: .env adalah nama umum yang digunakan proyek untuk mendefinisikannya pengaturan khusus aplikasi. Seharusnya tidak tercemar dengan pengaturan buruh pelabuhan kecuali pengembang benar-benar ingin melakukan itu. Namun keputusan ini harus diserahkan kepada pengembang.

Berikut sarannya: Bagaimana jika menambahkan dua opsi lain untuk nama proyek dan menghentikan penggunaan .env di V4 dari docker-compose.yml ? Salah satunya adalah project_name dalam docker-compose.yml , yang lainnya adalah file .dockerproject yang hanya berisi nama dan tidak boleh dikirimkan ke repositori. Ini harus berupa file lokal.

Inilah saran saya untuk diutamakan (tertinggi dulu):

• -p CLI argumen
• .dockerproject file
• project_name dalam docker-compose.yml (harus dihindari, jika docker-compose.yml didistribusikan bersama proyek)
• COMPOSE_PROJECT_NAME dari lingkungan
• COMPOSE_PROJECT_NAME dari .env (tidak digunakan lagi)
• nama direktori

Dengan cara ini, pengguna akhir masih dapat mengganti nama proyek di .dockerproject meskipun seseorang melakukan hardcode di docker-compose.yml didistribusikan.

UPDATE: Saya juga bisa hidup dengan menggunakan .dockerenv atau docker.env bukan .dockerproject . Tetapi itu harus memiliki prioritas yang lebih tinggi untuk menyelesaikan masalah, bahwa beberapa di sini perlu mengganti nama proyek hardcode di docker-compose.yml .

Halo semua,

Pertama-tama, terima kasih @dnephin dan @ shin- telah melihat kasus ini. Perubahan yang dikirimkan @ shin- tampaknya merupakan langkah yang bagus untuk menyelesaikan masalah ini.

Saya telah memvalidasi PR 5378 pada proyek uji untuk kasus penggunaan berikut: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900). Untuk itu saya membuat git repo yang menggambarkan berbagai kemungkinan: https://github.com/estarter/compose_745

Saya menemukan PR # 5378 mencakup sebagian kasus penggunaan. Masalahnya adalah solusinya membutuhkan variabel COMPOSE_X_PROJECT_NAME env. Solusi yang memungkinkan:

1. pertahankan variabel env di folder proyek. Saya mencoba file .env tetapi tidak berfungsi ketika docker-compose dipanggil dari lokasi lain (lihat contoh perintah , buat file )
2. tentukan COMPOSE_X_PROJECT_NAME secara global (.profile atau setara). Itu akan berhasil tetapi tidak dapat ditentukan dalam proyek, yaitu ini bukan solusi untuk kasus penggunaan kami defined by the project, that can be checked in
3. apakah ada pilihan lain?

Semoga saya berhasil menggambarkan kasus penggunaan yang dibahas di sini.

Para pengelola yang terhormat, harap pertimbangkan bagaimana kasus penggunaan diselesaikan dengan PR # 5369 yang memperkenalkan properti opsional project_name dalam file tulis-galangan. Properti ini mengambil prioritas rendah tetapi tidak bergantung pada lingkungan atau direktori kerja.

1. apakah ada pilihan lain?

Ada opsi ini docker-compose --project-directory <PATH> (Tentukan direktori kerja alternatif). Juga harus bekerja dengan file .env .

Untuk menambahkan use case bernuansa lain ke dalam campuran:
Dalam kasus penggunaan saya, saya memiliki dua repositori, satu untuk proyek utama (digunakan untuk membangun / menyebarkan) dan satu untuk devops (berisi Dockerfile's, docker-compose.yml, dll.)
Dalam pengaturan kami saat ini, repo proyek utama ada di root ./ dan repo devops diperiksa ke subdirektori ./devops/

Dalam penyiapan ini, menggunakan file .env tidak berfungsi karena harus:

ditempatkan di folder tempat perintah docker-compose dijalankan (direktori kerja saat ini).
(doc ref)

Yang tidak berhasil, karena dipanggil sebagai: docker-compose -f devops/docker-compose.yml
Tentu saja, kita dapat menambahkan parameter -p di sini, yang saat ini kita gunakan, tetapi rentan terhadap kesalahan manusia seperti yang telah dirujuk di atas.

Jika file .env (atau usulan docker-compose.env) dapat dibaca dari direktori yang sama tempat docker-compose.yml berada, maka menentukan nama proyek di sana akan berhasil untuk saya.

Menggunakan direktif env_file di dalam docker-compose.yml tidak berfungsi, karena env vars tersebut hanya diterapkan di dalam container, bukan untuk pembuatan container.

Pada akhirnya, tujuan saya adalah untuk menjaga file-file terkait devops saya berdiri sendiri dengan cara yang tidak mencemari basis kode proyek saya yang sebenarnya, tetapi masih dapat diakses / dijalankan secara paralel dengan repo itu.

Ada opsi ini docker-compose --project-directory(Tentukan direktori kerja alternatif). Juga harus bekerja dengan file .env.

@ schmunk42 bisa menjadi bidikan yang bagus, tetapi --project-directory tidak berfungsi untuk file .env. Saya mencoba sebagai berikut, file .env telah diabaikan ( file proyek ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

Untuk selanjutnya, saya akan menghapus komentar yang tidak berkontribusi pada percakapan dengan cara yang konstruktif. Saya tidak tertarik berinteraksi dengan anak-anak.

Tentang memiliki nama .env diatur
Masalah dengan memiliki variabel lingkungan yang menentukan file .env akan digunakan adalah bahwa itu pada dasarnya adalah ketergantungan melingkar. Kami harus memperkenalkan pengecualian dalam cara variabel lingkungan diinterpretasikan yang, meski masuk akal, secara inheren kontra-intuitif.

Pada nama .env itu sendiri
Sudah jelas sekarang bahwa nama .env digunakan oleh banyak perangkat lunak dan kerangka kerja, dan biasanya tidak dimaksudkan untuk digunakan dalam kontrol versi. Kami sangat sensitif untuk membuat perubahan yang mengganggu, tetapi kami dapat memperkenalkan nama alternatif (mis. docker-compose.env ) dengan penggantian ke file .env jika yang pertama tidak ada, dengan maksud bahwa itu mungkin dibagikan dengan pengguna lain.

Saat menambahkan project_name ke file Tulis
Kami telah mengulangi pendirian kami tentang hal ini beberapa kali - lihat komentar Daniel terbaru untuk beberapa alasan kami menentang melakukan perubahan itu. Itu tidak sulit. Bukannya kami tidak memikirkannya. Kami menghabiskan banyak waktu untuk mengevaluasinya, dan kami merasa kualitas proyek akan terlalu menderita sebagai akibat untuk membenarkan penambahannya (dalam formulir ini). Secara realistis, # 5378 mungkin adalah konsesi terbaik yang dapat kita buat agar ini berfungsi dengan cara yang dapat dipilih dan kompatibel ke belakang (EDIT: Tentu saja, saya terbuka untuk saran yang meningkatkan proposal itu dalam parameter ini)

Pada --project-directory
Sedikit bersinggungan, tetapi saya sadar opsi ini agak rusak sekarang. Dalam retrospeksi, saya lebih suka tidak menambahkannya sama sekali, karena itu menciptakan lebih banyak masalah daripada menyelesaikannya. Saya akan mencoba dan meluangkan waktu untuk melihat apakah itu dapat diperbaiki, tetapi memiliki banyak kasus tepi aneh yang membuatnya benar-benar tidak dapat diandalkan.

Dengan semua yang dikatakan, adakah orang yang docker-compose.env + # 5378 tidak akan menjadi solusi yang memuaskan? Saya mengerti ini mungkin bukan solusi favorit Anda, tetapi saya bertanya apakah itu membuat konsesi yang masuk akal yang dapat Anda atasi.

Semua bercanda samping ...

Saya masih tidak mengerti bagaimana komentar terakhir Daniel terkait dengan "kualitas proyek". Lebih lanjut, aturan umum yang umum bahwa menambahkan kunci ke kamus tidak boleh menyebabkan kerusakan kompatibilitas ke belakang. Selalu ada kasus di mana programmer telah mengimplementasikan sesuatu dengan cara yang tidak demikian, tapi saya ngelantur.

Saya pikir kamp yang menginginkan bidang project-name (atau apa pun) dibenarkan, karena "nama" proyek sangat penting bagi banyak aspek perkakas. Orang-orang di kamp ini mungkin ingin menuliskan nama ini di suatu tempat di batu untuk menghindari masalah dengan solusi yang lebih sementara seperti variabel lingkungan atau perintah seperti bendera.

Saya harap ini konstruktif.

@estarter Saya akan menganggap ini bug, mungkin ada baiknya untuk membuka masalah terpisah untuk itu

Sebenarnya saya berharap ini berfungsi dengan file .env di direktori PR_5378 :

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Tentang menambahkan nama_proyek ke file Tulis

@ shin- Sepertinya, keputusan sudah dibuat. Tapi saya masih mencoba memahami latar belakangnya. Saya sudah menanyakan ini sebelumnya dan tidak pernah mendapat jawaban (yang merupakan salah satu alasan mengapa diskusi terasa sangat mengganggu saya).

Bisakah Anda membantu saya memahami, mengapa kita memiliki container_name dan bahkan network dalam docker-compose.yml ? Yang pertama juga bisa menjadi sumber potensi konflik. Dan yang terakhir sangat spesifik untuk host. Mengikuti logika Anda, keduanya (dan lainnya) seharusnya tidak ada di sana. Saya gagal melihat perbedaan menjadi project_name .

Tolong, jangan abaikan pertanyaan ini lagi.

@ michael-k Apakah Anda mengatakan project_name sama dengan container_name ? Jika Anda berkata demikian, maka saya ingin memberi tahu Anda bahwa satu proyek dapat terdiri dari beberapa wadah. Atau apakah saya salah paham dengan Anda?

Sedangkan untuk network , itu belum tentu khusus untuk host. Ada banyak kasus ketika sebuah proyek membutuhkan jaringan terisolasi pusat di mana satu kontainer berinteraksi dengan jaringan lain. Dan konfigurasinya disimpan di docker-compose.yml .

@AyushyaChransh Anda salah paham. Pertanyaannya adalah: Mengapa container_name , network dan lainnya docker-compose.yml sedangkan project_name tidak diperbolehkan berada di sana? Mereka semua berbagi potensi yang sama untuk konflik atau konfigurasi khusus host yang tidak boleh dibagikan.

@aandan saya tahu tentang kesempatan ini. Juga, hal yang sama dapat diberitahukan tentang nama kontainer, tetapi kami memiliki kesempatan untuk menetapkan nama kontainer dalam file tulis, bukan?

Ya, tapi menurut saya menambahkan itu bukan ide yang bagus.

Dari diskusi terkait Tentukan nama jaringan dalam file tulis-buruh pelabuhan .

@estarter Saya akan menganggap ini bug, mungkin ada baiknya untuk membuka masalah terpisah untuk itu

@ schmunk42 saya melihat bahwa pengelola mengetahui hal ini - lihat On --project-directory dalam komentar Joffrey plus # 4709, # 4933 dan # 4841

Sebenarnya saya berharap ini berfungsi dengan file .env di direktori PR_5378:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Anda berasumsi bahwa --project-directory mempengaruhi parameter -f .
Sebenarnya bukan itu masalahnya, perintah ini memberi IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

Sangat bagus bahwa --project-directory tidak mempengaruhi -f - jika tidak bayangkan mimpi buruk apa yang akan terjadi jika menggunakan --project-directory dan beberapa file docker-compose semua dalam direktori yang berbeda.

Saya sangat terkejut melihat begitu banyak pertimbangan tentang sesuatu yang saya anggap sebagai masalah yang sudah diselesaikan.

Ini adalah urutan prioritas yang biasa saya lihat:

1. hardcode
2. opsi cli
3. lingkungan Hidup
4. project.rc
5. default waras

Untuk project_name saat ini kami tidak memiliki opsi # 1 atau opsi # 4. Ini adalah masalah mendasar yang dihadapi orang dan tampaknya mudah diselesaikan dengan cara yang kompatibel ke belakang.

Kami tampaknya memiliki argumen filosofis tentang kemurnian yang mungkin tidak membantu. Sebaliknya, menggunakan skema konfigurasi cascading OSS yang sangat umum, sangat membantu.

Kami tampaknya memiliki argumen filosofis tentang kemurnian yang mungkin tidak membantu.

Memiliki argumen ini sebenarnya bukanlah tujuan. Sejak awal , kami telah sangat jelas tentang posisi kami dalam menentukan nama proyek di file Tulis.

Tapi biarkan saya transparan tentang ini. Ini tidak akan pernah terjadi dalam docker-compose . Jika itu adalah satu-satunya jalur resolusi yang ingin Anda terima untuk masalah ini, maka Anda harus menggunakan proses OSS untuk mem-fork proyek dan melakukannya sendiri. Kode tersedia dan dibagikan dengan lisensi yang sangat permisif.

Bisakah Anda membantu saya memahami, mengapa kami memiliki container_name dan bahkan jaringan di docker-compose.yml? Yang pertama juga bisa menjadi sumber potensi konflik. Dan yang terakhir sangat spesifik untuk host. Mengikuti logika Anda, keduanya (dan lainnya) seharusnya tidak ada di sana. Saya gagal melihat perbedaan dengan project_name.

Untuk container_name , opsi itu diperkenalkan sejak awal masa proyek. Seperti yang ditunjukkan oleh @ schmunk42 , jika kita melakukannya lagi, ini pasti tidak ada dalam spesifikasi. Ini terus-menerus disalahgunakan dan telah menjadi sumber masalah yang tak terhitung jumlahnya bagi pengguna selama bertahun-tahun.
Adapun network , saya tidak sepenuhnya yakin bagaimana perbandingannya dalam pikiran Anda?

Bagaimana dengan opsi # 4 yang saya sebutkan? Saya melihat beberapa pembicaraan tentang memperkenalkan .docker-compose untuk pengaturan khusus direktori lokal. Ini akan jauh lebih disukai (imo) daripada memperkenalkan tanda lingkungan _x_ (yang masih memerlukan manajemen lingkungan).

Ini akan menjadi seperti ini:

# <my-project-dir>/.docker-compose
project_name: foobar

Di atas berbeda dari opsi variabel lingkungan dan lebih rendah dalam daftar prioritas.

Ini menyelesaikan kasus penggunaan saya dengan baik dan menandai jalur konfigurasi standar lain dari daftar.

@thedeeno Dalam pikiran kami, COMPOSE_PROJECT_NAME di dalam file .env sudah mencapai itu (dengan urutan prioritas yang sama seperti yang akan ada di garis besar Anda). Namun, kami telah mendengar Anda tentang .env menjadi pilihan nama yang buruk, itulah sebabnya kami mempertimbangkan docker-compose.env sebagai alternatif. Apakah itu berhasil untuk Anda?

Dalam pikiran kami, COMPOSE_PROJECT_NAME di dalam file .env sudah menyelesaikannya

@ shin- di sinilah kami tidak setuju. Saya tidak berpikir demikian.

Saya pribadi senang bahwa kami mencari file .env . Ini adalah tempat yang sangat konvensional untuk meletakkan rahasia lokal dan konfigurasi khusus perangkat keras lokal lainnya.

Ini berfungsi dengan baik untuk membantu dengan number 3 atas, konfigurasi berbasis lingkungan.

Itu tidak memberi kita jalan keluar ( number 4 ) ketika kita tidak ingin lingkungan memiliki nama proyek.

Dalam kasus saya, pengembang kami masing-masing akan memiliki file .env mereka sendiri (bukan VC). Ini berisi rahasia untuk injeksi ke docker-compose.yaml . Suka ini.

Kami tidak ingin pengembang memiliki kendali atas nama proyek, karena nama tersebut sangat terkait dengan beberapa perkakas. Karena .env tidak ada dalam kontrol versi, kita harus meminta para pengembang secara manual mengatur COMPOSE_PROJECT_NAME dengan pendekatan ini; dan itu _satu hal_ tidak seperti yang lain, karena ini bukan rahasia.

Jadi sayangnya tidak, hanya mengubah jalur sumber default dari .env tidak akan membantu kita di sini. Kami benar-benar senang bahwa .env bersumber secara otomatis. Kami hanya tidak ingin menentukan nama proyek seperti itu.

saya akan menunjukkan satu kasus penggunaan dari praktik saya:

Saya menggunakan file .env untuk menentukan versi gambar, dan untuk menghindari sed / awk / perl / parsing yang aneh, saya hanya menimpa nilai di CI:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

nanti di docker-compose.yml , gambar ditentukan sebagai:

    image: my.registry.example.net/app:${APP_VERSION}

sekarang jika saya membutuhkan lebih banyak variabel semacam itu, saya perlu melakukan beberapa parsing, kecuali beberapa file .env didukung.

jadi, mungkin juga tambahkan dukungan "direktori", seperti: docker-compose.env.d/* atau .docker-compose.env.d/* atau docker-compose.d/* .

tetapi karena glob tersebut dapat langsung membuat masalah mencocokkan cadangan editor ( *~ , *.bak ) lebih baik menggunakan beberapa ekstensi sebagai gantinya: docker-compose.env.d/*.sh

... tapi sekali lagi, mungkin hanya membuatnya dapat dikonfigurasi di docker-compose.yml .env file level root

sedikit offtopic, tapi COMPOSE_PROJECT_NAME env tidak mengizinkan kontrol penuh prefix, itu akan tetap dilucuti agar cocok dengan A-Za-z0-9_ ... saya ingin menggunakan - di prefiks saya. (Saya tidak dapat menemukan di mana saya melaporkan ini sekarang, tetapi afaik itu tidak ditujukan)

akan logis untuk mengizinkan karakter yang sama yang dibatasi oleh buruh pelabuhan itu sendiri.

@glensc Banyak sekali infrastruktur untuk mengelola lingkungan. Saya pribadi tidak berpikir itu adalah tanggung jawab docker-compose .

Satu-satunya hal yang pernah saya lihat dilakukan proyek lain adalah secara otomatis mendapatkan .env

@glensc @thedeeno Idealnya, kita memiliki dua file *.env , satu dimaksudkan untuk dibagikan dengan pengguna lain, dan satu lagi dirahasiakan, dengan yang terakhir menggantikan yang pertama ketika keduanya mendefinisikan var yang sama?

Saya membahas nama .env dikonfigurasi dalam komentar saya minggu lalu.

Memiliki publik docker-compose.env (sementara sumber pribadi masih otomatis .env ) akan bekerja dengan baik untuk kami!

Kami akan memperlakukannya seperti file rc dan melakukan kontrol sumber.

Saya pikir memiliki file env publik / pribadi, kemungkinan besar memecahkan sebagian besar kasus penggunaan yang disebutkan di sini. jika - akan diizinkan dalam nama proyek juga, itu akan bagus.

@thedeeno @glensc Bisakah Anda memberikan kasus penggunaan di mana Anda memerlukan file ENV pribadi yang menggantikan nilai di file publik?

Rahasia tidak boleh didefinisikan dalam docker-compose.env , karena mereka tidak akan diteruskan secara otomatis ke kontainer. Anda masih dapat menggunakan file .env dan melakukan apa pun yang diinginkan dengannya. Tapi kelihatannya membingungkan saya untuk menggabungkan pengaturan untuk docker-compose dan kontainer di tumpukan.

@ schmunk42 Saya tidak memiliki kasus penggunaan itu jadi saya tidak akan banyak membantu di sana. Saya hanya perlu mengkomit project_name ke kontrol versi. docker-compose.env menyelesaikannya.

Tidak yakin saya mengikuti paragraf kedua Anda. Kami menggunakan .env untuk rahasia dan secara manual menyuntikkannya ke docker-compose.yaml .

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

itu hanya karena HANYA tempat untuk mendefinisikan ${variables} untuk image nilai tampaknya menjadi .env file.

@glensc Setuju!

Namun sebaliknya, saya akan mengusulkan docker-compose.override.env untuk menyelaraskannya dengan fitur penggantian saat ini untuk yml file.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Tidak yakin saya mengikuti paragraf kedua Anda. Kami menggunakan .env untuk rahasia dan secara manual menyuntikkannya ke docker-compose.yaml.

@thedeeno Saya berasumsi Anda melakukan ini:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

yang juga dapat dilakukan dengan docker-compose.override.env . Atau Anda bisa melakukan:

env_file:
  - .env

Apakah Anda menyarankan untuk menghapus .env untuk mendukung penulisan yang lebih spesifik untuk buruh pelabuhan
jalan?

Jika kita melewatkan sumber otomatis .env, itu akan berdampak negatif pada file
alur kerja tim. Kami mengandalkan file ini untuk perkakas lainnya. Kami akan berakhir
menempatkan rahasia kita dalam dua (.env dan file lain yang Anda sarankan)
tempat jika buruh pelabuhan-menulis berhenti melihat .env.

Pada Kamis, 23 November 2017 pukul 01.15 Tobias Munk [email protected]
menulis:

@glensc https://github.com/glensc Setuju!

Tapi sebaliknya, saya akan mengusulkan docker-compose.override.env untuk menyelaraskannya
fitur penggantian saat ini untuk file yml.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

Tidak yakin saya mengikuti paragraf kedua Anda. Kami menggunakan .env untuk rahasia dan
secara manual menyuntikkannya ke docker-compose.yaml.

@thedeeno https://github.com/thedeeno Saya berasumsi Anda melakukan ini:

lingkungan Hidup:

• $ {SECRET_VAR_FROM_DOTENV}

yang juga dapat dilakukan dengan docker-compose.override.env. Atau kamu
bisa melakukan:

env_file:

• .env

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/745#issuecomment-346538315 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
.

Apakah Anda menyarankan untuk menghapus .env untuk mendukung penulisan yang lebih spesifik untuk buruh pelabuhan
jalan?

Belum tentu, untuk BC docker-compose masih bisa melihat .env jika yang lain tidak ditemukan, sama seperti fig.yml sekali. Meskipun mungkin sulit untuk memutuskan kasus berikut:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env tidak akan digunakan dalam kasus terakhir, tetapi saya ragu-ragu bagaimana menangani dua yang pertama, karena beberapa pengguna akan menggunakan .env sebagai pengganti, yang lain sebagai pengganti.

Bagi saya .env harus digunakan dalam semua kasus. Ini adalah file dengan arti khusus
di ekosistem yang lebih luas.

Dalam kasus ketiga Anda, ini hanya file dengan prioritas terendah.

Yang saya butuhkan hanyalah cara untuk memasukkan nama proyek saya ke kontrol sumber. Bukan saya
sangat peduli dengan lingkungan cascading yang lebih canggih
pengelolaan. Saya sebenarnya lebih suka strategi nama proyek ini tidak memiliki apa-apa
lakukan dengan variabel lingkungan.

Jika file konfigurasi berada di luar tabel dan ada cara untuk memasukkan file
project_name dengan env cascade yang Anda gunakan, saya akan dengan senang hati menggunakannya
meskipun!

Pada Kamis, 23 November 2017 pukul 01.31 Tobias Munk [email protected]
menulis:

Apakah Anda menyarankan untuk menghapus .env untuk mendukung penulisan yang lebih spesifik untuk buruh pelabuhan
jalan?

Belum tentu, untuk BC buruh pelabuhan masih bisa melihat .env jika
yang lain tidak ditemukan, sama seperti fig.yml sekali. Meskipun mungkin saja
sulit untuk memutuskan kasus berikut:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env tidak akan digunakan dalam kasus terakhir, tetapi saya ragu-ragu bagaimana menanganinya
ke dua yang pertama, karena beberapa pengguna akan menggunakan .env sebagai pengganti, yang lain sebagai
fallback.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/745#issuecomment-346539891 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AAFId95kZQIsiWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
.

Mengenai jaringan, saya tidak sepenuhnya yakin bagaimana perbandingannya menurut Anda?

@ shin-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

Sepertinya saya salah melakukannya, karena saya tidak pernah menyerahkan docker-compose.yml saya ke repo saya. Itu selalu berisi pengaturan khusus host yang sangat tinggi. Itu dapat memiliki konten yang sangat berbeda dalam mengembangkan sebuah produksi.

Saya adalah penggemar "4 project.rc" meskipun saya mungkin akan menggunakan sesuatu seperti docker-project.yaml daripada format yang berbeda. Ini persis seperti yang dijelaskan oleh masalah asli. Sejauh yang saya ketahui, setiap diskusi tentang meletakkan nama proyek di file tulis harus berada dalam masalah terpisah.

Yang saya butuhkan hanyalah cara untuk memasukkan nama proyek saya ke kontrol sumber.

Ini masih poin yang saya tidak mengerti. Seharusnya tidak ada alasan untuk meminta satu nama proyek dengan kode keras. Jika ada perkakas eksternal yang mengharapkan nama yang konsisten, mengapa perkakas itu tidak menyetel nama proyek sebelum memanggil docker-compose ?

my_project_network_on_my_localhost sepertinya salah bagi saya. Mengapa Anda memerlukan nama proyek di jaringan eksternal? Tidak perlu sama dengan nama proyek tulis.

my_project_network_on_my_localhost sepertinya salah bagi saya.

Ini hanya sebuah contoh. Saya memiliki penyiapan jaringan yang berbeda di mesin pengembangan lokal saya daripada di server produksi. Banyak pengaturan lain di docker-compose.yml juga secara teratur berbeda dari produksi, misalnya saya memiliki wadah utilitas yang ditentukan di sana untuk membangun barang-barang khusus proyek atau memelihara database atau apa pun.

Seperti yang saya pahami, awalnya ide utama di balik docker-compose (atau lebih baik fig ) adalah, untuk mengatur dengan baik semua opsi baris perintah docker yang panjang untuk penyiapan container yang kompleks dalam file yaml sederhana. Itulah mengapa rasanya sangat aneh, sehingga hanya ada satu opsi yang ditinggalkan. Tapi sepertinya saya merindukan bahwa ini bukan lagi ide utama di baliknya.

Banyak pengaturan lain di docker-compose.yml saya juga secara teratur berbeda dari produksi, misalnya saya memiliki wadah utilitas yang ditentukan di sana untuk membangun barang-barang khusus proyek atau memelihara database atau apa pun.

Kami memiliki alur kerja yang sama di sini. Dalam kasus kami, definisi penulisan buruh pelabuhan "umum" pada dasarnya hampir tidak ada , tetapi ini adalah satu-satunya hal yang benar-benar dibagikan di antara dev, pengujian, pementasan, dan produksi.
Bagian utama dari pengaturan pengembangan ditentukan dalam file terpisah, penggabungan otomatis dilakukan melalui file .env . Ini sama untuk pengaturan pengujian .

Karena dalam folder dalam kasus kami, kami dapat melakukan sesuatu seperti

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

untuk pengujian ... atau ini

(cd production && docker-compose logs -f --tail 100)

untuk produksi (Bonus: Anda dapat menentukan DOCKER_HOST dalam produksi untuk mengarah ke mesin lain, tetapi hanya dengan docker-compose ).

Tapi ya, ini folder, bukan file - dan membutuhkan cp .env-dist .env di dua tempat untuk bekerja, jika tidak maka gagal dengan file penulisan yang tidak valid. Sebenarnya saya hanya ingin membagikan alur kerja IMHO yang rapi ini.

Ini masih poin yang saya tidak mengerti. Seharusnya tidak ada alasan untuk meminta satu nama proyek dengan kode keras. Jika ada perkakas eksternal yang mengharapkan nama yang konsisten, mengapa perkakas itu tidak menyetel nama proyek sebelum memanggil docker-compose?

@dnephin Ada alasannya.

Ya, ada solusi. Permintaannya adalah membuatnya lebih nyaman dan dapat diprediksi.

Berikut salah satu contoh di mana nama proyek hard-code membantu: konfigurasi buruh pelabuhan traefik default untuk membuat aturan host untuk kontainer dalam format berikut: <service>.<project>.<domain> . Format ini tidak mudah diubah. Sangat bermanfaat bagi pengembang kami untuk menggunakan fqdns yang sama untuk layanan pembuatan galangan kapal kami. Akan lebih baik jika kita dapat menggunakan konfigurasi nol-konfigurasi, karena berdiri satu-satunya cara untuk menjamin konsistensi adalah dengan: a) memaksa mereka menggunakan nama direktori tertentu untuk klon mereka b) secara manual menetapkan aturan untuk traefik. Keduanya payah.

Ini satu lagi: mereferensikan gambar yang dibuat dengan docker-compose. Jika kami tidak dapat menjamin nama proyek, kami tidak dapat menjamin nama gambar ini dan tidak dapat merujuknya dengan yakin. Tentu, kami dapat melakukan hardcode image_name untuk setiap definisi tetapi terus terang itu terasa berlebihan karena kami _ ingin menggunakan konvensi_ tetapi hanya khawatir bahwa pengembang yang memilih untuk menggunakan nama file yang berbeda akan mengalami kegagalan yang sangat mengejutkan dalam perkakas kami.

Teman-teman, begitu banyak diskusi ... apa status ini, dapatkah saya menetapkan nama proyek default di file .docker-compose ?
Atau masih butuh lebih banyak diskusi di utas ini?

Menyimpan nama proyek dalam file docker-compose.yml lebih masuk akal bila digunakan dengan alat lain, misalnya PyCharm.

Akan sangat bagus untuk menyimpannya dalam file YAML yang sama tetapi mungkin menimpa jika diperlukan.

Saya pikir inti dari masalah ini berasal dari fakta bahwa nama proyek default secara sederhana (haruskah saya katakan _naively_?) Diambil sebagai nama dasar direktori saat ini. Ini secara efektif mengompresi ruang nama sistem file (hierarki) menjadi datar, yang bermasalah karena konflik nama. Misalnya, ini menyebabkan masalah bagi orang yang menjalankan layanan di ~/fooproject/master dan ~/barproject/master .

Saya pikir nama proyek itu tidak penting. Jadi mungkin cara untuk membuat pembuat galangan-galangan kuat adalah dengan menghasilkan nama proyek berdasarkan jalur lengkap (yaitu home_flaviovs_fooproject_master )?

Saya suka ide yang gigih itu. Untuk dapat memasukkan nama proyek ke Git adalah kasus penggunaan yang umum. Mungkin membaca file .env.default sebelum .env adalah solusi sederhana untuk ini (yang mana BTW akan mengurus # 210 yang bertahan lama juga)?

Saya menyelesaikan ini dengan membungkus biner docker-compose dengan fungsi saya sendiri sehingga saya dapat memanggil fungsi tersebut dari mana saja. Ini memuat file .env dan menggunakan file docker-compose yang tepat di mana saja.

Jelas Anda bisa memperluas ini untuk memiliki fungsi per proyek atau sesuatu. Saya pikir mungkin ada kekurangannya tetapi saya belum menemukannya.

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

Saya memiliki masalah dengan tabrakan gambar, dan itu terlihat sangat aneh bahwa saya tidak dapat mengatur nama_proyek di docker-compose.yml karena terlihat sangat logis dan solusi yang lurus ke depan. Sebenarnya mengambil nama dari folder proyek di tempat pertama adalah ide yang buruk. Dalam banyak kasus, folder proyek bisa seperti / home / project1 / repository, / home / project2 / repository dan seterusnya, dalam hal ini buruh pelabuhan membuat nama gambar yang sama seperti repository_app.

@vedmant Anda dapat menyetel nama gambar di docker-compose.yml , cukup gunakan image dan build .

Jadi ... Bagaimana kalau dipisahkan oleh proyek di folder bernama sama sekarang?

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

Mungkin ini sudah diusulkan. tetapi mengapa tidak membuat perubahan besar di version: 4 dan menambahkan beberapa kata kunci baru untuk memungkinkan pengaturan nama proyek dari docker-compose.yml ?

.docker-compose / project-name saya tidak berfungsi ...
--project-name berhasil

Saya juga ingin menetapkan nama proyek di docker-compose.yml.

Kasus penggunaan saya adalah, saya memiliki file docker-compose.yml yang memiliki aplikasi web dan layanan database pasca-kemajuan.
Saya juga ingin memisahkan file docker-compose.yml untuk tugas-tugas adhoc - pada dasarnya menjelaskan tugas-tugas adhoc yang ingin saya atur dengan docker-compose. Tugas adhoc ini perlu memanfaatkan layanan / jaringan / volume yang sama seperti yang digunakan dalam proyek utama.

Contoh tugas adhoc yang ingin saya atur dengan docker-compose mungkin saja. memigrasi data ke database postgress . Ini berguna untuk mengatur ini dengan docker-compose karena tugas mungkin melibatkan pemintalan layanan dan volume tambahan, jaringan, dll, di samping yang saat ini, untuk memenuhi tugas itu.

Jadi untuk mencapai ini, saya dapat membuat file terpisah docker-compose.adhoctask.yml untuk mewakili tugas, sehingga saya dapat menjalankan tugas itu sesuai permintaan hanya jika diperlukan. Karena berada di direktori yang sama dengan file penulisan-buruh pelabuhan asli, ia mendapatkan nama proyek yang sama secara default sehingga memiliki akses ke jaringan yang sama, volume, dll.? dan semuanya berhasil.

Namun masalahnya muncul ketika saya tidak ingin file yml tugas adhoc ini tinggal di direktori tingkat atas yang sama (atau bahkan repo yang sama) sebagai docker-compose.yml . Sebagai contoh, mungkin saya ingin meletakkan tugas adhoc docker-compose.adhoc.yml dalam subfolder, dengan DOCKERFILE dan aset yang dibutuhkan tugas dengan baik diisolasi / dikelompokkan bersama sebagai urusannya sendiri. Segera setelah saya memindahkannya ke subfolder, nama proyeknya tidak lagi cocok. Ini berarti tidak lagi memiliki akses ke volume / jaringan yang sama dll yang ditentukan dalam proyek utama.

Jika saya dapat menentukan projectname di docker-compose.yml dan docker-compose.adhoc.yml - maka saya dapat menyusunnya sesuka saya (bahkan menaruhnya di repo terpisah) dan tetap menjalankannya tanpa harus terus-menerus menentukan argumen baris perintah tambahan atau mengganti variabel lingkungan.

Ini adalah masalah nyata bagi saya, karena menyebabkan konflik penamaan

Saya memiliki beberapa proyek dalam struktur

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

sekarang ketika saya memulai penulisan galangan dalam satu proyek, itu membuat jaringan backend_default dan mengawali kontainer yang tidak secara eksplisit dinamai dengan backend_ .. sekarang Jika saya ingin memulai proyek lain, saya punya untuk kembali ke folder yang benar dan pertama-tama menjalankan docker-compose down untuk mencegah konflik - jika tidak maka akan memulai penampung baru di jaringan yang sama, dan kemudian saat mematikannya, ia akan mengeluh tentang orhan, padahal tidak ada.

Juga menjadi masalah bagi saya. Saya memiliki banyak proyek, dan menggunakan docker-compose untuk demo dinamis berdiri di satu mesin, satu stand per cabang.

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

Jadi "master" dan "devs" saling bertentangan di antara proyek. File .docker-compose bisa menyelesaikannya.

@simplesmiler Dengan risiko mengulang kembali, .env sudah menyelesaikannya.

@ shin- .env sering digunakan untuk rahasia yang tidak ada dalam kontrol versi.

Apa yang diinginkan @simplesmiler adalah cara untuk memasukkan nama proyek ke kontrol versi _ sambil mempertahankan .env luar kontrol versi_.

Sejauh yang saya tahu, masih belum ada cara untuk melakukan ini dengan mudah.

@thedeeno bukan itu yang dikatakan postingan mereka. Apakah kalian bekerja sama? Jika tidak, kita tidak boleh menganggap kasus penggunaan orang lain melebihi apa yang tertulis secara eksplisit.

Kami tidak bekerja sama. Itulah interpretasi saya tentang masalah mereka. Poin yang benar-benar adil, saya mungkin salah dan saya mungkin berasumsi.

Saya berharap KITA bekerja sama agar kita bisa minum kopi. Saya harap Anda tidak berpikir saya brengsek di sini.

Mungkin saya hanya salah mengingat utas ini: Apakah ada cara untuk memasukkan nama proyek ke kontrol versi sambil membiarkan .env diabaikan?

Adakah cara untuk memasukkan nama proyek ke kontrol versi sambil tetap membiarkan .env diabaikan? Atau apakah ini masih merupakan kemampuan yang hilang?

Tidak saat ini. Seperti yang saya sebutkan beberapa bulan yang lalu ^ 1, rencananya adalah memiliki docker-compose.env sebagai file env sekunder yang dapat disertakan dalam kontrol versi. Ini agak merosot ke bawah daftar prioritas tetapi saya berharap bisa segera melakukannya.

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

Itu berita bagus! Menerima PR?

Saya sudah lama putus asa tetapi mari kita coba lagi:

Saya rasa banyak di sini yang masih gagal untuk memahami mengapa kami terpaksa mempertahankan file kedua untuk pengaturan ini.

Seperti yang saya pahami, untuk beberapa di sini hal itu merusak pengaturan proyek mereka. Namun bagi mayoritas di thread ini hal tersebut tidak akan menjadi masalah. Jadi bagaimana mungkin segelintir orang itu memberlakukan pembatasan ini kepada semua orang lain yang tidak memiliki fitur ini? Mengapa kami tidak dapat memiliki beberapa opsi untuk cara mengonfigurasi nama dan kemudian menyerahkan keputusan kepada kami?

Ini bahkan tidak masuk akal secara logis: Kurangnya pengaturan ini di docker-compose.yml sangat jelas sehingga saya bahkan tidak percaya bahwa opsi ini hilang ketika saya mencarinya di manual. Hampir setiap aspek lain dari penyiapan Anda dapat dikonfigurasi di sana. Bagi saya itu adalah jeda yang jelas dalam logika konfigurasi.

Saya pikir orang bisa mengatakan, (hampir) semua pengaturan di docker-compose.yml "dibatasi" oleh nama proyek .

Seperti yang disarankan di # 4841, opsi untuk menentukan file .env mana yang akan digunakan (yaitu --env-file ) akan sangat berguna.

@roipoussiere lihat https://github.com/docker/compose/issues/4841#issuecomment -414543951

Terima kasih @ schmunk42.
Tapi itu artinya saya harus membuat hierarki seperti:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

alih-alih sesuatu yang lebih mudah seperti:

.
├── a.env
├── b.env

Ya, lihat juga https://github.com/docker/compose/issues/745#issuecomment -345054893 - Anda mungkin perlu membukanya di jendela baru, karena terkadang tersembunyi di sini : nerd_face:

Saya menyetujui proposal --env-file . Membuat tiket hanya untuk itu. Pergi dan sukai jika Anda menginginkan opsi ini.

Jadi saya hanya membaca sedikit komentar tentang bug / fitur ini, dan fakta bahwa diskusi berlanjut dan terbuka membawa saya pada kesimpulan bahwa sudah 4 tahun sejak pertama kali dibuka dan masih belum ada solusi? Bisakah kita membuat keputusan parsial dan kemudian bergerak maju ..?

Saya akui, saya belum membaca seluruh masalah ini dan semua masalah terkait tetapi ada masalah menarik seputar topik ini yang membuat ini lebih rumit daripada yang terlihat pada pandangan pertama. Misalnya, seperti yang kita semua tahu .env biasanya digunakan untuk nilai rahasia, jadi Anda biasanya mengabaikannya dari kontrol versi.

Tapi katakanlah Anda bekerja dengan Stripe, yang memungkinkan Anda memiliki kunci uji dan kunci langsung, AKA. 2 set kunci untuk digunakan. Dalam pengembangan, akan sangat umum bagi Anda untuk menggunakan kunci pengujian, dan dalam produksi Anda akan menggunakan kunci langsung.

Itu secara otomatis berarti Anda tidak dapat menggunakan .env dengan sendirinya untuk menangani nilai rahasia karena Anda akan memiliki kunci yang berbeda di setiap lingkungan, dan Anda tidak ingin harus mengganti nilai dalam file Anda antara menjalankan aplikasi di dev atau prod (itu akan gila dan rawan kesalahan super).

Apa yang mungkin Anda lakukan adalah membuat file .env dan .env.prod dan mengabaikan keduanya dari kontrol versi. Dengan cara ini Anda dapat memiliki kunci test / dev dalam pengembangan dan kemudian mereferensikannya dengan env_file dalam file penulisan pengembangan Anda.

Namun kemudian dalam produksi Anda mereferensikan .env dan .env.prod dalam file penulisan produksi Anda.

Tapi apakah Anda melihat ke mana arahnya? Saat ini Docker Compose tidak mengizinkan Anda memiliki file opsional env_file . Jika file tidak ada, maka Docker Compose akan meledak segera setelah Anda mencoba menjalankan Docker Compose.

Jadi Anda secara otomatis membutuhkan file .env untuk tetap ada jika Anda berencana menggunakannya dengan env_file dan ini juga tidak terbatas pada Stripe. Banyak kerangka kerja web memiliki pengaturan tertentu yang spesifik lingkungan tetapi akan berubah baik dalam pengembangan dan produksi (mis. SERVER_NAME dengan Flask).

Jadi itu berarti kita dibatasi untuk memiliki sesuatu seperti file .env_example yang Anda komit ke kontrol versi dan diharapkan pengguna akhir mengganti nama file itu menjadi .env , dan kemudian di dalam file ini akan berisi teman lama kita COMPOSE_PROJECT_NAME .

Yang sekarang memunculkan pertanyaan. Apakah sebenarnya kita membutuhkan cara alternatif untuk mengatur nama proyek? Saya tidak yakin kami melakukannya, tetapi saya yakin menyetel nama proyek kustom adalah ide yang bagus dalam proyek apa pun, atau setidaknya sesuatu selain nama folder karena Anda dapat dengan mudah mengalami konflik nama.

Apakah masalah ini ada di beberapa peta jalan?

Kasus penggunaan untuk ini adalah untuk memodifikasi COMPOSE_PROJECT_NAME dalam kasus di mana proyek Anda memiliki beberapa file docker-compose (misalnya satu untuk dev, test, mungkin basis, mungkin tes lokal, dll.) Anda mungkin perlu memutar up 2 lingkungan yang sangat berbeda yang terpisah satu sama lain.

Dalam kasus kami, kami dapat mengatasi batasan penulisan galangan ini dengan membuat COMPOSE_PROJECT_NAME di makefile kami.

Saya ingin melihat ini dapat dikonfigurasi dari dalam yaml penulisan itu sendiri.

Apakah ini masih buka? Ya Tuhan...

Berlangganan. Saya juga ingin dapat menetapkan nama proyek di file compose yaml.

Ini berlangsung selamanya 🤦‍♂

akan sangat membantu jika memiliki fitur ini

fitur ini akan sangat diterima dalam proyek yang saya kerjakan

Ok, jadi dari utas panjang ini kita dapat menyimpulkan bahwa nama proyek tidak akan ada di file docker-compose.yml, karena pengembang utama menentang ini dan tidak akan menggabungkan permintaan tarik seperti itu.

Jadi, bisakah kita kembali ke proposal asli di bagian atas masalah ini: untuk membuat nama proyek tetap ada. Menggunakan file .docker-compose atau direktori .docker-compose terdengar bagus bagi saya. Tapi alangkah baiknya jika kita akhirnya bisa mendapatkan beberapa kemajuan dalam penerapannya.

Saya akan menambahkan variabel ENV ke daftar alternatif itu.

Akar substansial dari semua ketidaksepakatan adalah utas / masalah ini adalah bahwa bagi banyak orang itu tidak berfungsi jika berada dalam variabel ENV. Mereka ingin dapat memasukkannya ke repo (opsional tentu saja, rekomendasi standarnya adalah untuk tidak melakukannya.)

Memiliki ENV daripada konten yaml bertentangan dengan filosofi berbagi file yaml antara proyek yang berbeda. Bahkan secara resmi didokumentasikan: https://docs.docker.com/compose/extends/ (Lihat "Contoh kasus penggunaan" misalnya). Jika Anda menggunakan file yaml basis tunggal, lalu menimpa file untuk dev, test, dan prod, dan entah apa lagi, tidak masuk akal untuk menjalankannya dengan nama proyek yang sama atau menyetel nama proyek dengan ENV / cli. Ini hanya akan membuat kombinasi N * N sedangkan pada N valid.

Saya telah menjelajahi beberapa diskusi ini dan melihat BANYAK komentar dari orang-orang yang menginginkan nama proyek dapat dikonfigurasi di file YML. Tetapi tidak ada satu pun komentar yang menjelaskan mengapa hal itu tidak boleh dilakukan. Diskusi ini sudah ada sejak lama.

Sebagai seseorang yang mencari solusi yang mudah digunakan dan menemukan bahwa tidak ada cara mudah untuk mengatur nama proyek yang tidak memerlukan perhatian pengguna yang cermat pada baris perintah yang dieksekusi (yang bersaing dengan ide inti alat yang Anda gunakan. lulus up dan secara ajaib memulai cluster server penuh) - Saya terkejut bahwa ini adalah pertanyaan terbuka. Jika ada penjelasan yang jelas mengapa ini bermasalah atau mengkhawatirkan untuk diterapkan, saya akan tertarik.

solusi elegan dapat menggunakan placeholder di properti container_name (dan penamaan dinamis lainnya seperti volume, jaringan, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

dengan konfigurasi seperti itu, seseorang dapat menggunakan

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

edit: ini bukan solusi yang tepat, karena akan menimbulkan konflik bagi orang yang menggunakan 2 proyek berbeda dalam nama folder yang sama

@tokopedia

solusi elegan dapat menggunakan placeholder di properti container_name (dan penamaan dinamis lainnya seperti volume, jaringan, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

dengan konfigurasi seperti itu, seseorang dapat menggunakan

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

edit: ini bukan solusi yang tepat, karena akan menimbulkan konflik bagi orang yang menggunakan 2 proyek berbeda dalam nama folder yang sama

Saya juga melakukan ini dan berpikir ini akan memperbaiki masalah konflik, meskipun kita masih perlu mengatur variabel COMPOSE_PROJECT_NAME ke beberapa nilai unik pada file .env .

Pada titik ini, saya benar-benar hanya ingin memahami alasan pengelola menolak solusi. Sudah ada permintaan tarik untuk solusi.

Begitu kita tahu apa yang salah, barulah kita bisa memperbaikinya. Pada titik ini, saya tidak melihat umpan balik selain "ditolak".

Kami memiliki 2 komentar ini:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

Tetapi saya harus mengakui bahkan membaca komentar itu, saya tidak sepenuhnya mengerti mengapa tidak menambahkan project_name ke file yaml. Bagi mereka yang berpikir itu membuat file docker-compose.yaml mereka kurang umum, mereka seharusnya tidak memasukkan nama di file yaml, tapi tolong biarkan kita memiliki pilihan untuk melakukannya.

Oke, saya melakukan yang terbaik untuk membaca referensi ke komentar lain; akan sangat menghargai setidaknya uraian singkat yang mereferensikan konten dalam referensi, selain referensi untuk membantu memastikan saya membaca hal yang benar dan mendapatkan konten yang tepat.

Izinkan saya mencoba meringkas apa yang saya lihat adalah kekhawatiran. Bantuan apa pun untuk menjelaskan hal ini akan sangat kami hargai.

(1) Menambahkan nama proyek ke file YML dapat membuat proyek kurang dapat digunakan kembali karena akan mencegah, atau setidaknya memperumit, menjalankan satu file YML dengan lebih dari satu nama proyek.
(2) "kualitas proyek akan sangat menderita sebagai akibat untuk membenarkan penambahannya (dalam bentuk ini)"
(3) "Jika nama proyek ada dalam file tulis, maka dua proyek mana pun dapat menggunakan nama yang sama, menyebabkan konflik, yang akan merusak kedua proyek."

Saya memiliki pemikiran tentang ini, tetapi saya akan menahan komentar sampai kami dapat menyetujui masalah yang perlu ditangani. Apakah itu masuk akal?

(4) Implementasi dengan cara yang kompatibel ke belakang (prioritas / urutan nilai)

(1) Menambahkan nama proyek ke file YML dapat membuat proyek kurang dapat digunakan kembali karena akan mencegah, atau setidaknya memperumit, menjalankan satu file YML dengan lebih dari satu nama proyek.

Sekali lagi, ada cara resmi untuk membagi konfigurasi menjadi basis dan file dan diwariskan - https://docs.docker.com/compose/extends/. Seseorang tidak dapat menyiapkan nama proyek di konfigurasi dasar.

Bagi saya, kasus penggunaan utama yang saya cari adalah kemampuan untuk menjalankan beberapa contoh proyek secara lokal (dev, lingkungan pengujian, dll).

Mungkin solusinya adalah mengizinkan Anda menyetel nama proyek secara eksplisit atau jalur traversal.

Jika saya menetapkan nama proyek di file yaml secara eksplisit seperti my-project maka dapat menyederhanakan hal-hal untuk satu contoh proyek atau di mana saya melakukan sesuatu seperti menambahkan semua file buruh pelabuhan saya di folder docker di banyak proyek.

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

Tapi ini tidak membantu dengan banyak contoh dari proyek yang sama, jadi bagaimana kalau melakukan sesuatu dengan jalur traversal

project_name: ../(*) jadi dengan contoh yang sama

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

demikian pula project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

bagaimana menentukan traversal mungkin harus dipikirkan sedikit lebih mendalam daripada ibu jari saya, tetapi setidaknya dengan melakukan ini saya pikir kami memiliki fleksibilitas untuk mencakup semua kasus penggunaan.

Hanya setengah bercanda: Itu berarti mengkonfigurasi nama tetap di docker-compose.yml saya, saya akan membuat file dengan nama yang saya inginkan, dan kemudian menetapkan project_name: name-of-the-file-named-like-the-name-i-want ?

Saat ini saya memiliki beban file docker-compose dalam direktori yang sama. Seperti dc-work.yml , dc-server.yml , dll., Yang semuanya memuat layanan yang berbeda dan tidak terkait.

Ketika saya menjalankan docker-compose up dc-A.yml , dan kemudian menjalankan docker-compose up dc-B.yml , Docker mengomeli saya bahwa ada layanan yatim piatu yang berjalan (tentu saja tidak, itu karena nama proyek terkutuk).

Apakah benar-benar tidak ada cara untuk menyelesaikan ini? Memindahkan setiap file dc-A|B|C|etc.yml ke direktorinya masing-masing, lalu menelusuri setiap file untuk memuat semua layanan saya sepertinya membuang-buang waktu, atau saya melewatkan sesuatu?

Mengapa masalah ini belum ditangani? Solusi yang jelas dan langsung disajikan oleh @ cr7pt0gr4ph7 di sini: https://github.com/docker/compose/issues/745#issuecomment -182296139. Itu menerima banyak suara. Setiap perhatian telah dibahas dalam diskusi. Dan, yang paling penting, ini memecahkan banyak masalah bagi banyak orang. Apa yang memberi?

Juga mengalami masalah ini karena kami menggunakan struktur direktori proyek tetap dengan folder .docker yang berisi semua hal yang terkait dengan buruh pelabuhan, jadi saya berakhir dengan banyak nama proyek .docker - Saya sedang mengerjakan arsitektur layanan mikro jadi normal untuk memiliki beberapa up ... tetapi hal kecil ini, terus menghalangi -> juga, PHPStorm dll tidak memiliki opsi untuk meneruskan argumen -p / - project-dir dan saya tidak bisa benar-benar menggunakan .env untuk ini karena, percayalah, pengaturan nilai yang tepat akan dilupakan ...

Pengembang, beri tahu kami bagaimana Anda ingin masalah ini diselesaikan.

Mungkin menambahkan properti ke file docker-compose untuk menyetel nama proyek?

@Ayushrans

Pengembang, beri tahu kami bagaimana Anda ingin masalah ini diselesaikan.

Ini adalah ringkasan terbaik:
https://github.com/docker/compose/issues/745#issuecomment -182296139

Ada banyak diskusi. Tidak perlu diskusi lebih lanjut. Pengelola proyek hanya perlu membaca utas (jamak) dan melakukan yang diperlukan.

Bagi saya masih seperti ini: https://github.com/docker/compose/issues/745#issuecomment -248644429

Bagi saya ini masih ini: # 745 (komentar)

Ya, ada solusi yang ada, tetapi solusi yang buruk. Komentar-komentar tersebut telah ditolak dan masalah telah dinyatakan dengan jelas oleh banyak orang. Komentar yang ditautkan tidak membahas sebagian besar masalah sah yang diangkat di utas ini.

Ya ampun, itu semacam titik diperdebatkan. Banyak dari kita telah pindah ke Kubernetes dengan fungsionalitas tipe docker-compose . Ini sedikit bertele-tele. Tapi itu berfungsi dan didukung dengan baik oleh vendor cloud.

@Ayushrans
Kami ingin menggunakan mekanisme untuk menetapkan nama proyek seperti yang dijelaskan di sini: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. Baris perintah arg.
2. Variabel lingkungan (file .env)
3. Di file Tulis secara langsung
4. Jalur folder

Jangan berpikir ada keberatan atas hal ini.

Ada, ini tentang portabilitas, seperti yang disebutkan di atas, entah bagaimana mirip saat menggunakan container_name , yang seharusnya juga bukan bagian dari docker-compose.yml . Anda tidak dapat menggunakan kembali konfigurasi yang sama dengan pengaturan yang ada.

Jika alur kerja Anda bergantung pada jalur folder dan entah bagaimana project-name dimasukkan ke dalam konfigurasi Anda, mis. melalui penggabungan, beberapa file tulis, template, ... - Anda akan mendapatkan masalah yang sama - menimpa tumpukan yang ada.

Maaf untuk mengatakan ini, tapi ini harus ditutup sebagai wontfix .. (edit) atau rilis versi MAJOR (!) Baru

@ rizky_dwi

Jika alur kerja Anda bergantung pada jalur folder dan entah bagaimana nama proyek dimasukkan ke dalam konfigurasi Anda, mis. melalui penggabungan, beberapa file tulis, template, ... - Anda akan mendapatkan masalah yang sama - menimpa tumpukan yang ada.

Pertama, nama proyek hanya akan disetel di file compose oleh mereka yang membutuhkannya dan itu karena mereka ingin file compose bekerja dengan stack yang ada. Anda dapat menambahkan peringatan Anda ke dokumen seputar pengaturan ini.
Kedua, bagi mereka yang mengandalkan nama proyek tertentu, pertimbangkan ini:

1. Bagaimana jika file compose didownload dari git repo, lalu di commit berikutnya pemilik repo memindahkannya ke sub folder yang berbeda? Atau mengganti nama foldernya? Dampak pada alur kerja sudah ada karena file dapat dipindahkan dan memengaruhi nama proyek.
2. Jika Anda mengandalkan nama proyek tertentu, kami telah mengusulkan mekanisme untuk memastikannya, baik dengan menggunakan variabel lingkungan (file .env) atau menggunakan argumen baris perintah saat menjalankan penulisan Docker - keduanya akan menimpa nilai apa pun yang kebetulan ada di file tulis (jika ada yang ditambahkan karena alasan tertentu).

Menutup ini sebagai wontfix tidak terlalu membantu tanpa menjelaskan mengapa hal di atas tidak cukup baik .. atau menawarkan jalan menuju solusi.

Saya tidak ingin alur kerja saya (atau lebih tepatnya alur kerja seluruh tim saya) bergantung pada nama folder tempat mereka memeriksa kode.

Masalah utama saya dengan solusi file .env adalah file ini harus berada di direktori kerja dari perintah run - sedangkan docker-compose menyelesaikan file penulisan ke direktori induk. Oleh karena itu, menjadi penting bahwa semua pengembang baik (A) memeriksa kode ke dalam folder bernama yang sama (dengan asumsi file docker-compose.yml di root repo kode) atau (B) hanya menjalankan perintah docker-compose di folder root dari repo jika tidak membuat tumpukan yang bertentangan atau (C) mereka memiliki nama tumpukan yang berbeda dan semua dokumentasi dan skrip harus mengatakan replace stack name here .

Jika (C) adalah apa yang disarankan pekerja galangan sebagai solusi 'portabel' yang disarankan maka CLI pembuat galangan perlu dilengkapi fitur lengkap dengan perintah CLI pekerja galangan dan, meskipun demikian, saya masih melihat kasus penggunaan untuk fitur ini.

Jika alur kerja Anda bergantung pada jalur folder dan entah bagaimana nama proyek dimasukkan ke dalam konfigurasi Anda, mis. melalui penggabungan, beberapa file tulis, template, ... - Anda akan mendapatkan masalah yang sama - menimpa tumpukan yang ada.

Jika nama-proyek ditambahkan ke file tulis-buruh pelabuhan, itu pasti ada di sana karena suatu alasan (seperti setiap baris lain dalam file tulis-buruh pelabuhan). Sayangnya saat ini bahkan hanya mengganti nama folder check out saya (tidak membuat perubahan terlacak di git) saya juga mendapatkan sistem yang rusak.

Saya tidak percaya ini tahun 2020 dan kami masih belum memperbaiki kasus penggunaan besar ini. Ini bukan perubahan besar, adalah fitur yang sepenuhnya opsional dan masuk akal. Mengingat Kubernetes sekarang adalah alat penyebaran defacto untuk buruh pelabuhan, saya membayangkan docker-compose untuk sebagian besar melihat penggunaan dalam pengembangan / penerapan lokal dan memiliki file tulis-buruh pelabuhan di root repositori untuk menjalankan kode di repo secara lokal adalah yang sangat populer kasus penggunaan.

@ dc-pm menulis: "Mengingat Kubernetes sekarang menjadi alat penerapan de facto untuk buruh pelabuhan"

Saya sekarang tidak lagi menulis file docker-compose. Tidak ada cukup manfaat untuk sesuatu yang tidak akan menghasilkan. Kubernetes juga memiliki keunikannya sendiri. Tetapi ini didukung secara luas oleh vendor cloud.

Sejujurnya, berurusan dengan container di lingkungan pengembangan saya terlalu merepotkan dari hari ke hari. Saya baru saja menjalankan program ...

@ dc-pm menulis:

Saya tidak percaya ini tahun 2020 dan kami masih belum memperbaiki kasus penggunaan besar ini.

Bukan hanya itu belum diperbaiki, tetapi para pengembang secara aktif menolak untuk memperbaikinya.

Masalahnya, saya menduga, adalah bahwa remaja yang mengembangkan perangkat lunak ini tidak memiliki pengalaman mendalam untuk memahami implikasi kasus penggunaan ini, atau mendengarkan sejumlah besar pengguna yang lebih berpengalaman yang meminta penanganannya. Pada titik ini saya ragu mereka telah bekerja di lingkungan dengan lebih dari satu tumpukan, atau mungkin bahkan dalam tim. Jika tidak, terus terang, _ini akan menjadi peningkatan yang sangat jelas! _

Beberapa pengingat ramah ...
Pengembang sumber terbuka bukanlah "karyawan / perguruan tinggi" Anda, dalam banyak kasus mereka kebanyakan bekerja secara gratis.
Jika ini jelas merupakan masalah bagi Anda, luangkan waktu untuk menyelidiki solusinya (dan dorong PR).

Menyalahkan bukanlah solusinya.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

Cukup sulit untuk mendorong perubahan ketika pengembang menentangnya ...

Pada Sab, 14 Mar 2020 pukul 03:19, Antoine Gravelot [email protected]
menulis:

Beberapa pengingat ramah ...
Pengembang open source bukanlah "karyawan / perguruan tinggi" Anda, dalam banyak kasus
mereka kebanyakan bekerja secara gratis.
Jika ini jelas merupakan masalah Anda, luangkan waktu untuk menyelidiki solusinya
dan mendorong PR.

Menyalahkan bukanlah solusinya.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/745#issuecomment-598991880 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
.

@agravelot Saya rasa ada beberapa PR, mungkin tidak ideal. Tetapi melalui semua diskusi, pemilik telah menetapkan harapan dengan sangat jelas bahwa mereka tidak menginginkan fitur ini. Ini bukan masalah pengkodean.

@agravelot maaf atas keterlambatannya. Dan saya benar-benar tidak bermaksud untuk tidak menghormati banyak orang hebat dan berbakat yang berkontribusi di sini. Tapi menyalahkan kurangnya usaha juga tidak membantu.

Saya hanya menyoroti dukungan dari sebuah ide yang belum pernah didengarkan dalam banyak kesempatan meskipun dukungan yang jelas dalam jangka waktu yang sangat lama. Inti dari ini (dan OSS secara umum) sebagaimana didefinisikan dalam kode etik kami adalah untuk memungkinkan orang menyumbangkan kode dan menghormati semua ide.

Sudah ada beberapa permintaan tarik yang dibuat, tetapi jika itu akan membantu situasi, saya sangat senang untuk membuat yang lain.

Apa cara yang lebih konstruktif untuk maju?

Sudah ada beberapa permintaan tarik yang dibuat, tetapi jika itu akan membantu situasi, saya sangat senang untuk membuat yang lain.

Ya, pengembang harus melanjutkan dengan meninjaunya, atau menutup ini sebagai "Tidak akan diperbaiki" (mungkin berdebat) ... Menjaga ini tetap terbuka selama bertahun-tahun, tanpa umpan balik resmi, itu hanya membuang-buang waktu kontributor (dalam arti luas ). Ini juga tidak sopan, IMO.

Hai, teman-teman, sebagai pengguna, saya hanya ingin berbagi kasus penggunaan saya. Jadi saya memiliki 2 file docker-compose.yml, satu untuk lingkungan pengembangan, satu untuk produksi. Mereka berada di folder yang sama. Keduanya memiliki layanan dengan nama yang sama - disebut "database". Saya ingin menerapkan kedua layanan ini pada saat yang sama - hanya karena saya bisa, yang sedang kita bicarakan adalah containerization, saya dapat menskalakan sebanyak yang saya inginkan. Mereka memiliki nilai "container_name" yang berbeda.

Jadi saya menjalankan:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

Perhatikan bagaimana dikatakan "Membuat ulang database-dev" sementara saya dengan jelas merujuk ke layanan yang terletak di proyek "prod". Sebenarnya menimpa penampung yang ada. Basis data dihentikan dan wadah diganti dengan yang terakhir.

Saya melakukan ini dengan asumsi bahwa file "docker-compose.yml" yang terpisah berarti proyek yang terpisah, tetapi tampaknya ini bukan masalah dalam kehidupan nyata. Proyek tempat layanan diterapkan ditentukan oleh lokasi "docker-compose.yml". Untuk membuatnya menjadi bagian dari proyek terpisah, saya perlu menentukan nama proyek secara terpisah dalam variabel lingkungan. Ini akhirnya bekerja dengan ini:

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

Begitu banyak untuk penerapan perintah tunggal, sungguh lelucon yang mutlak. Menurut pendapat saya, .yml adalah tempat yang tepat untuk menentukan nama proyek dalam konteks ini.

Alternatifnya, saya dapat menempatkan layanan ke dalam satu proyek - dengan memberi mereka nama yang berbeda: "database-dev" dan "database-prod". Satu-satunya masalah dengan pendekatan ini adalah bahwa ada peringatan tentang layanan yang sebelumnya dipakai menjadi yatim piatu karena tidak disebutkan di docker-compose.yml lainnya.

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

Ini tidak masuk akal tbh, kenapa harus seperti ini. MENGAPA sebenarnya harus seperti itu?

EDIT1: @ dc-pm @CharlieReitzel bagaimana menurutmu? bisakah Anda memberikan komentar tentang kasus penggunaan saya, untuk berjaga-jaga jika tidak valid :)
EDIT2: Saya telah menempatkan kedua file compose ke dalam direktori dan voila terpisah

sooo?

pengelola, ada orang di sini?
pengembang menunggu selama 6 tahun!

Hai! Saya membuat masalah di compose-spec agar nama proyek ditambahkan ke skema penulisan karena itu mengatur apa yang dapat kita tambahkan ke file penulisan.
Setelah properti nama-proyek ditambahkan ke spesifikasi penulisan, kita dapat memulai implementasi di docker-compose.