Moby: `docker stack deploy` di 1.13 tidak memuat file `.env` seperti halnya `docker-compose up`

Ini adalah dengan desain. Dukungan .env adalah fitur Compose, bukan format file.

Kita bisa mendiskusikan menambahkan ini untuk rilis mendatang, tapi saya tidak tahu apakah itu benar-benar pilihan terbaik.

Dukungan .env cukup berguna dalam Compose, kami menggunakannya di banyak file penulisan kami. Ini memisahkan bagian dinamis dan bagian statis dari file docker-compose.yml . Dengan memuat .env secara default, kami hanya dapat menyediakan file .env yang berbeda untuk lingkungan yang berbeda, dan menjaga docker-compose.yml dan skrip terkait tetap statis.

Tidak mungkin menggunakan env_file atau environment dalam docker-compose.yml untuk mencapai hasil substitusi envvars yang sama. .env adalah cara paling mudah untuk melakukannya.

Jika tidak, kita harus memberi awalan export di setiap baris file .env dan secara manual source .env setiap kali sebelum memuat docker-compose.yml , dan langkah-langkah tambahan terkadang rawan untuk kesalahan.

Saya baru menyadari ini.
Saya berasumsi/mengharapkannya berfungsi dengan cara yang sama seperti untuk Compose, tetapi tidak demikian untuk docker deploy .

Dalam kasus khusus saya, saya mengharapkan untuk menggunakan file .env untuk menyimpan data sensitif (kata sandi, kunci API, dll) yang digunakan dalam layanan yang akan saya buat di tumpukan:

version: '3'

volumes:
  data:
    driver: local

networks:
  backend:
    driver: overlay

services:
  rabbitmq:
    image: rabbitmq:${EXCHANGE_RABBITMQ_TAG}
    volumes: [ "data:/var/lib/rabbitmq" ]
    logging: { driver: gelf, options: { gelf-address: "udp://0.0.0.0:12201" } }
    networks: [ "backend" ]
    ports: [ "15672:15672", "5672:5672" ]
    environment:
      RABBITMQ_DEFAULT_USER: ${EXCHANGE_RABBITMQ_USER}
      RABBITMQ_DEFAULT_PASS: ${EXCHANGE_RABBITMQ_PASS}
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.labels.queue-host == true

Sementara file Compose ini akan diperiksa di Git, file .env akan diabaikan.

Saya telah mengikuti seluruh hal/sejarah file *.dab vs compose, dan saya merasa kalian mencoba untuk menghindari sesuatu - atau mengusulkan solusi yang lebih baik - tetapi saya kehilangan jejak seluruh diskusi...

Halo semua,

Versi buruh pelabuhan: v1.13.0-rc4

Saya mendapatkan kesalahan: Mengabaikan opsi yang tidak didukung: build , Apakah itu berarti tidak akan membuat build dari Dockerfile ?

Dan juga mendapatkan kesalahan yang sama untuk network_mode: Mengabaikan opsi yang tidak didukung: network_mode.

Di bawah ini adalah perintah:
DOCKER_IMAGE=akhil123 tumpukan buruh pelabuhan menyebarkan -c buruh pelabuhan-compose.yml foo

Banyak terima kasih sebelumnya.

@akhildangore tolong jangan mengomentari masalah dengan pertanyaan yang tidak terkait langsung. Fitur docker stack deploy , _by design_ tidak melakukan build. Alasan untuk ini adalah bahwa _build_ dilakukan pada host tempat perintah dijalankan, sehingga gambar hanya akan tersedia di node _that_. Saat menyebarkan gambar itu di Swarm, layanan tidak dapat dimulai pada node lain. Untuk menyebarkan layanan, pastikan gambar yang Anda gunakan didorong ke registri (atau untuk pengujian; pastikan gambar tersedia di setiap node di swarm)

Apakah ada kasus/diskusi yang mendukung/menentang mendukung perilaku ini pada docker deploy ?

@vovimayhem belum ada keputusan yang dibuat pada file .env , tetapi Anda mungkin tertarik pada https://github.com/docker/docker/pull/30144 , yang menambahkan dukungan untuk rahasia ke file penulisan

Saya baru saja menemukan diskusi itu. Bagus sekali!

Saya menggunakan fungsi bash sebagai solusinya.

Anda dapat menyesuaikannya dengan kebutuhan Anda hingga fitur secrets dirilis:

dsd() {
    stack=${1:-${PWD##*/}} # by default, the name of the cointaining folder
    compose_file=${2:-docker-compose.yml}

    if [ ! -f $compose_file ]; then
        echo "Misses compose file: $compose_file" >&2
        return 1
    fi

    # execute as a subcommand in order to avoid the variables remain set
    (
        # export variables excluding comments
        [ -f .env ] && export $(sed '/^#/d' .env)

        # Use dsd your_stack your_compose_file to override the defaults
        docker stack deploy --compose-file $compose_file $stack
    )
}

Bagi mereka yang berlangganan masalah ini; dukungan rahasia untuk file-file docker-compose akan disertakan dalam rilis 1.13.1, yang seharusnya tidak terlalu jauh di masa mendatang

@whoan Saya menggunakan ini sebagai solusi:

env $(cat .env | grep ^[A-Z] | xargs) docker stack deploy --compose-file docker-compose.yml [STACK_NAME]

Dengan begitu, variabel tidak macet di jendela terminal

Selalu menyenangkan memiliki kemampuan untuk memuat sesuatu dari file .env - selain kasus penggunaan rahasia Docker yang lebih sederhana yang sekarang dapat dielakkan, selalu ada nilai Docker Compose yang tidak ingin Anda hardcode di repo Anda.

Mari kita asumsikan Anda menggunakan docker stack deploy untuk menyebarkan tumpukan lengkap dan Anda memiliki persyaratan berikut:

• Anda ingin menggunakan konfigurasi yang sama persis untuk lingkungan yang berbeda - katakanlah pementasan dan produksi
  
  
  
  • Anda harus memiliki nilai skala yang berbeda untuk setiap lingkungan
  
  

Jika Anda tidak dapat mengonfigurasi ini dengan file .env , Anda perlu mengubah file docker-compose.yml secara manual sebelum menerapkan tumpukan setiap kali, jika tidak, nilai skala layanan akan kembali ke 1.

Anda dapat memperluas hal di atas dengan hal-hal seperti jaringan, mengonfigurasi DNS yang harus didengarkan oleh layanan, dll.

Saya dapat menyusun PR yang akan memuat file .env , jika ada di direktori yang sama dengan docker-compose.yml jika kami yakin kasus penggunaan di atas masuk akal.

Desain dari docker stack deploy sedikit berbeda dari perintah docker-compose . Saya tidak berpikir masuk akal untuk hanya membaca .env secara default. Bahkan docker-compse.yml tidak dibaca secara default, karena di masa mendatang sumber penyebaran default kemungkinan akan menjadi sesuatu yang lain.

Anda selalu dapat mencari sendiri file .env sebelum menjalankan stack deploy .

Hanya . .env sebelum memanggil docker stack deploy tidak membantu, $variables tidak diganti. Hanya trik env .. xargs yang membantu.
Akan menyenangkan untuk memiliki opsi --env-file=FILE seperti di docker run .

Hanya . .env sebelum memanggil penyebaran tumpukan buruh pelabuhan tidak membantu

Ini akan membantu @C-Pro - Anda harus memiliki baris export ... .env di file .env Anda. Atau, Anda dapat melakukan export $(cat .env) , yang akan berfungsi untuk sebagian besar kasus.

Halo semua,
Hari ini saya mencoba menjalankan docker stack deploy .
File docker-compose.yml saya:

version: '3'
services:
  simple:
    image: alpine
    environment:
      - FOO: ${BAR}
    env_file: .env

Dan file .env di direktori yang sama:

BAR=worked

Setelah meluncurkan docker stack deploy -c docker-compose.yml test , saya memeriksa wadah dan mendapatkan ini:

$ env
BAR=worked
FOO=
...

Tampaknya, .env disediakan dalam wadah, tetapi tidak disediakan di mesin Host.
Artinya, saya dapat menggunakan file .env sebagai ganti bagian environment , tetapi saya tidak dapat menggunakan file .env dengan Substitusi Variabel.
Versi buruh pelabuhan: v17.03

@ddpaimon
lingkungan:
- FOO=${BAR}

Sepertinya file .env hanya berfungsi untuk wadah, tetapi tidak untuk penggantian variabel file docker-compose.yml.

Docker untuk MAC, Docker versi 17.03.1-ce, build c6d412e

@realcbb
Ya. Tetapi untuk menggunakan variabel file .env di dalam container, Anda harus menghapusnya di bagian environment .
Sebagai contoh:
docker-compose.yml

...
environment:
  - FOO=${FOO:-empty}
...

.env

FOO=filled

Dalam wadah saya mendapatkan ini:

$ env
FOO=empty

Tetapi jika saya menghapus FOO dari bagian environment di docker-compose.yml , saya mendapatkan ini:

$ env
FOO=filled

@ddpaimon
Variabel lingkungan yang ditentukan dalam lingkungan menimpa nilai-nilai ini yang ditentukan dalam file .env.

@dnephin : Anda menyatakan bahwa .env bukan bagian dari format file penulisan buruh pelabuhan. Namun, fitur file .env didokumentasikan dalam referensi Compose file versi 3: https://docs.docker.com/compose/compose-file/#variable -substitution .
Ini memberi kesan .env juga harus bekerja dengan penyebaran tumpukan buruh pelabuhan.
Selain itu, seperti yang telah disebutkan oleh orang lain, memisahkan nilai spesifik lingkungan aktual dari definisi tumpukan yaml adalah fitur yang sangat diinginkan/dibutuhkan. Secara khusus kami ingin menggunakannya untuk menentukan versi gambar dan ulangan.

Terima kasih, saya membuka https://github.com/docker/docker.github.io/issues/3654 untuk memperbaiki dokumen

docker stack deploy dapat mengambil file yang dihasilkan. Ini berfungsi di bash untuk semua variabel saya dan juga merahasiakan rahasia:

docker stack deploy --with-registry-auth --compose-file=<(ENV1=value1 ENV2=value2 docker-compose -f docker-compose.yaml -f docker-compose.override.yaml -f third-sample-compose.yaml config) stack-name

Harap dicatat saya menambahkan variabel ENV sebaris sebagai variabel tambahan atau penggantian. File penulisan saya merujuk file .env dan ini berfungsi. Semoga bermanfaat 👍

Fungsi docker-compose config adalah apa yang mengikat ini bersama-sama.

Saya menemukan masalah ini ketika mencari solusi untuk .env saya tidak dibaca oleh docker stack deploy . Saya agak terkejut melihat itu tidak didukung (dokumen dapat diklarifikasi), tetapi ingin menambahkan dukungan saya untuk .env , seperti compose.

Kasus penggunaan saya adalah saya menggunakan docker stack deploy di lingkungan dev, pengujian, staging dan menggunakan variabel lingkungan untuk opsi tumpukan agar file yml tetap sama.

Saat ini menggunakan salah satu solusi yang diposting di sini tetapi menggunakan file .env akan menjadi rute yang lebih disukai.

Hanya pengingat ramah: Mungkin ada kemungkinan Anda mencoba menggunakan file dotenv untuk menyimpan kunci API, kata sandi & hal-hal lain yang dianggap "sensitif" untuk dimasukkan ke dalam cluster. Untuk kasus ini, Anda harus menggunakan Rahasia Docker .

Untuk hal-hal lain, bolehkah saya menyarankan untuk memiliki satu file penulisan per lingkungan yang digunakan/dapat diterapkan? Sebagian besar hal yang berubah di antara lingkungan yang berbeda adalah server yang tersedia, organisasi server yang berbeda, dll... dan dengan demikian memerlukan nilai yang berbeda pada konten kunci deploy placement , resources reservasi, dll), membuat menggunakan satu file untuk semuanya agak terlalu rumit.

Sebenarnya saya menginginkan fitur ini, variabel dalam file penulisan dapat diperlakukan sebagai nilai yang berbeda pada Host yang berbeda saat menggunakan penyebaran tumpukan buruh pelabuhan.

"Untuk hal-hal lain, bolehkah saya menyarankan untuk memiliki satu file penulisan per lingkungan yang digunakan/dapat diterapkan? Sebagian besar hal yang berubah di antara lingkungan yang berbeda adalah server yang tersedia, organisasi server yang berbeda, dll... dan dengan demikian memerlukan nilai yang berbeda pada kunci penerapan konten (aturan penempatan, reservasi sumber daya, dll), membuat penggunaan satu file untuk semuanya menjadi sedikit terlalu rumit."

@vovimayhem Maaf berterus terang, tapi itu tidak masuk akal seperti menggunakan satu file penulisan dengan substitusi variabel menggunakan env_file. Saya lebih suka menggunakan format env_file karena ini juga memudahkan saya untuk menyediakan tumpukan sebagai kiriman ke pelanggan saya dan melatih mereka untuk memperbarui satu file vars gaya ini daripada mengacaukan file penulisan (yang saya TIDAK 'T ingin).

@ntwrkguru https://docs.docker.com/engine/swarm/configs/

Konfigurasi layanan adalah tambahan yang bagus, tetapi tampaknya tidak dapat digunakan untuk interpolasi waktu penerapan (mis. $TAG).

Jika variabel lingkungan didukung sama sekali, maka konsistenlah dalam mekanisme yang digunakan untuk menyelesaikannya di seluruh alat. Stack deploy tampaknya memilih untuk tidak konsisten, tanpa mengubah perilaku variabel lingkungan secara mendasar. Rahasia dan konfigurasi layanan adalah alternatif yang lebih baik untuk beberapa penggunaan variabel lingkungan, tetapi tidak termasuk.

Anda sepertinya tidak mengerti @vovimayhem. Saya tidak berbicara tentang meneruskan envs ke wadah; yang bekerja seperti yang diharapkan. Maksud saya adalah menggunakan env_file yang diuraikan selama stack deploy seperti selama compose up .

@ntwrkguru Saya hanya berpikir fitur baru ini akan membantu Anda... Sayang sekali tidak.

Ini masih berfungsi sebagai alternatif;

$ echo 'BAR=worked' > ./.env

$ export $(cat .env) && docker stack deploy testing -c -<<'EOF'
version: '3'
services:
  simple:
    image: nginx:alpine
    environment:
      FOO: ${BAR}
    env_file: .env
EOF

$ docker inspect testing_simple -f '{{json .Spec.TaskTemplate.ContainerSpec.Env}}'
["BAR=worked","FOO=worked"]

@thaJeztah , memang begitu. Saya memiliki tugas di buku pedoman saya untuk mencari file lingkungan, tetapi itu kehilangan poin yang lebih besar. Ini dulu mungkin dengan compose dan sekarang tidak mungkin dengan stack . IMO, itu regresi. Juga, dalam contoh Anda, Anda masih meneruskan variabel lingkungan ke dalam wadah. Saya bisa melakukannya dengan env_files hari ini; masalahnya adalah mengurai env_file selama operasi stack deploy -c docker-compose.yml .

Ini sangat menyakitkan karena stack tidak lagi mendukung banyak file penulisan, jika tidak, orang dapat menggunakan file penulisan sekunder per lingkungan. Untuk melakukannya dengan cara itu, seseorang perlu membuat file tumpukan dari file penulisan, memperkenalkan langkah lain. Jadi, bagaimanapun Anda melihatnya, kami beralih dari proses satu langkah ke proses multi-langkah untuk mencapai hasil akhir yang sama.

Juga, FWIW, configs benar-benar di bawah standar dalam pengalaman saya untuk konfigurasi aktual. Saya membayangkan (berharap) bahwa saya dapat memiliki /application/config.conf sebagai sumber. Perbarui file itu, komit, Dorong, dan CI akan menyebarkan kembali tumpukan dengan konfigurasi baru. Itu tidak mungkin tanpa peretasan untuk mengubah nama file atau mekanisme lainnya. Tentunya kita dapat memeriksa jumlah file, minimal, atau memindai perubahan konten dan memperbarui berdasarkan file itu sendiri? Secara keseluruhan, sepertinya kita akan mundur. Berikan dukungan untuk K8 sekarang dan itu membuat saya bertanya-tanya apakah swarm hanya akan merana di pokok anggur sampai kehilangan penggunaan yang cukup sehingga diam-diam dijatuhkan.

Juga, FWIW, konfigurasinya benar-benar di bawah standar dalam pengalaman saya untuk konfigurasi sebenarnya. Saya membayangkan (berharap) bahwa saya dapat memiliki /application/config.conf di source. Perbarui file itu, komit, Dorong, dan CI akan menyebarkan kembali tumpukan dengan konfigurasi baru. Itu tidak mungkin tanpa peretasan untuk mengubah nama file atau mekanisme lainnya.

@ntwrkguru Solusi sederhana adalah mengubah bukan nama file, tetapi nama konfigurasi itu sendiri. Saya menggunakan skema versi untuk nama konfigurasi saya, misalnya config_v1 , config_v2 , ..

Jadi ingatlah untuk meningkatkan versi itu setelah mengubah file konfigurasi.

services:
  app:
    [...]
    configs:
      - source: config_v2
      - target: /config.yml

configs:
  config_v2:
    file: ./config.yml

Saya memahami alasan di balik belum memiliki konfigurasi & rahasia berversi, jadi secara pribadi saya saat ini baik-baik saja dengan solusi (mudah) ini.

Terima kasih @djmaze , tetapi pada akhirnya itu adalah hal konyol yang perlu dilakukan ketika ada pelacakan versi bawaan yang terpasang di setiap sistem kontrol sumber. Juga, terima kasih atas tautannya; Saya juga berkomentar di sana. Saya tidak mengerti mengapa Docker peduli dengan versi selain yang saat ini. Satu-satunya alasan saya bisa melihat untuk versi yang diperlukan ini adalah untuk rollback, tetapi banyak hal perlu dilacak di sana juga, jadi apa lagi? (kata orang yang tidak perlu menulis kode) :-)

Coba ini:
echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name

Ia menggunakan komposisi buruh pelabuhan untuk mengurai file konfigurasi, mengganti env vars, menghapus peringatan dari output dan kemudian menyalurkannya ke tumpukan buruh pelabuhan yang disebarkan melalui stdin.
Ganti '-f stack.yml' dengan nama file konfigurasi Anda atau hilangkan untuk menggunakan docker-compose.yml default.

+1

Setahun kemudian dan kami masih harus meretas ini agar berfungsi. Mulai 17.09.1, docker stack deploy -f compose.yml bahkan tidak akan menggantikan menggunakan vars Shell yang dikenal.

$ printenv | grep PORTAINER
PORTAINER_VER=1.14.3

portainer:
    image: "portainer/portainer:${PORTAINER_VER}"

$ sudo docker stack deploy -c /tmp/docker/jedi-core.yml --with-registry-auth --prune --resolve-image always jedi-core
Updating service jedi-core_redis_server (id: 0csjyandro713y13ncitk6c0k)
Updating service jedi-core_api-gateway (id: gzcz2eturuxqkjojsc9e6954l)
Updating service jedi-core_auto_results_api (id: tw43c6e0x98q6f0m2g0zttwhf)
Updating service jedi-core_auto_results_api_mongo (id: qpwpypyzd9aigpa71xgxxdzcp)
invalid reference format

Variabel apa pun untuk tag akan menghasilkan invalid reference format .

Setahun kemudian dan kami masih harus meretas ini agar berfungsi. Mulai 17.09.1, docker stack deploy -f compose.yml bahkan tidak akan menggantikan menggunakan var shell yang dikenal.

lihat Bagaimana menjaga Variabel Lingkungan saat Menggunakan SUDO

$ export PORTAINER_VER=1.14.3
$ printenv | grep PORTAINER
PORTAINER_VER=1.14.3

$ sudo printenv | grep PORTAINER

$ sudo -E printenv | grep PORTAINER
PORTAINER_VER=1.14.3


$ cat > docker-compose.yml <<'EOF'
version: '3'
services:
  portainer:
    image: "portainer/portainer:${PORTAINER_VER}"
EOF


$ sudo -E docker stack deploy -c docker-compose.yml foobar
Creating network foobar_default
Creating service foobar_portainer

$ sudo docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                        PORTS
vt4h0g8yygcg        foobar_portainer    replicated          1/1                 portainer/portainer:1.14.3   

Terima kasih, tetapi adakah kata tentang hanya mendukung substitusi variabel dari file?

[ sunting ] Ini seharusnya tidak menjadi masalah (tetapi bisa jadi) karena saya menggunakan Ansible untuk melakukan tugas dengan become: yes , tetapi pengguna masih merupakan pengguna yang sama dengan sumber lingkungan vars.

Aku tidak percaya ini tidak mungkin. Kami ingin menyimpan satu file tumpukan dan dapat mengubah opsi penerapan menggunakan variabel dinamis.

Ini akan berhasil tetapi jelek dan meretas:

echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name

Saya telah mengotak-atik ini selama berjam-jam dan sepertinya melakukan beberapa pekerjaan skrip latar belakang (saya akan menggunakan CI untuk melakukan ini) untuk membuat file DAB dari berbagai bagian ini. Akan menyenangkan untuk memiliki alat buruh pelabuhan yang akan melakukan ini... :-) Mungkin menambahkan --env-file version.env ditambahkan ke docker-compose bundle ?

Dalam kasus penggunaan saya, saya ingin menggunakan "manifes" version.env untuk melacak dan mengontrol versi wadah/gambar yang terdiri dari sebuah platform. Proses saya terlihat seperti ini:

• Perbarui file .env
• Sumber file .env untuk mengisi shell vars
• Jalankan docker-compose -f stack.yml config > docker-compose.yml
• Jalankan docker-compose pull untuk mendaftarkan intisari gambar
• Jalankan file DAB docker-compose bundle -o stack.version.dab

Pada titik ini, idealnya saya dapat docker deploy --host manager.swarm.com --bundle-file stack.version.dab --with-registry-auth --resolve-image always stack-name , tetapi saya mengerti bahwa itu tidak mungkin sekarang. Dalam hal ini, saya akan scp file DAB ke manajer dan menjalankan docker deploy .

Apakah ini alur kerja yang dipikirkan Docker @thaJeztah? Apakah ada cara yang lebih baik?

[edit] Ini tidak berfungsi karena DAB mengabaikan arahan volume: , network: , dan deploy: . Saya telah mengambil sumber file env ke Shell, membangun kembali file penulisan sementara, lalu menyebarkannya.

Saya akan senang jika file .env dibaca secara default seperti di Docker Compose dan --env-file (pendek -e ) akan ditambahkan untuk docker stack deploy agar dapat ditimpa variabel lingkungan dan default dari file .env .

+1
Akan sangat nyaman untuk membaca .env di tempat pertama seperti yang dilakukan oleh docker-compose.
Baik secara default atau cukup lewati file env sebagai parameter di baris perintah tumpukan buruh pelabuhan.

Dua solusi yang telah disebutkan (_temukan juga di bawah_) tampaknya berfungsi meskipun sedikit jelek dibandingkan dengan 'perbaikan' yang diusulkan.

_echo "$(docker-compose -f stack.yml config 2>/dev/null)" | tumpukan buruh pelabuhan menyebarkan -c- stack_name_

_env $(cat .env | grep ^[AZ] | xargs) docker stack deploy --compose-file docker-compose.yml [STACK_NAME]_

Saya akan menambahkan bahwa menginstal docker-compose hanya untuk dapat memproses variabel-variabel ini juga bisa sangat berbahaya sebenarnya.

Jika ada yang menyebarkan tumpukan menggunakan docker-compose up -d secara tidak sengaja alih-alih menggunakan docker stack deploy, kemungkinan besar akan menyebabkan kesalahan aplikasi dan korupsi file.

Memiliki interpolasi variabel lingkungan dalam penerapan adalah solusi terbaik untuk integrasi berkelanjutan.

Satu masalah dengan penggunaan '.env' adalah tumpang tindih dengan nama file serupa yang digunakan oleh, misalnya, Ruby on Rails, memiliki kemampuan untuk menentukan file lingkungan dengan argumen lebih unggul.

Saran @ntelilil diterima dengan baik, dapat ditambah atau dimodifikasi dengan:

https://unix.stackexchange.com/questions/294835/replace-environment-variables-in-a-file-with-their-actual-values :

Anda dapat menggunakan envsubst (bagian dari gnu gettext):
envsubst < infile

saya menggunakan:

$ envsubst < docker-compose.yml-template > docker-compose.yml

Dan itu berfungsi dengan baik, tetapi saya perlu menambahkan sekitar 3Mb ke wadah saya.

Bagus @rnickle , tapi masih "retas" dibandingkan dengan Docker yang bisa melakukan ini seperti dulu. Tampaknya (dan tolong Docker dudes perbaiki saya jika saya salah) bahwa ada sedikit upaya untuk masuk ke mode swarm sejak pengumuman dukungan K8, jadi saya ragu salah satu dari regresi ini akan ditangani.

Dan itu berfungsi dengan baik, tetapi saya perlu menambahkan sekitar 3Mb ke wadah saya.

Jika variabel lingkungan disetel, docker slack deploy seharusnya sudah menginterpolasinya

dibandingkan dengan Docker yang dapat melakukan ini seperti dulu.

Docker tidak pernah memiliki fitur ini; menulis buruh pelabuhan memiliki; docker compose dan docker stack menyebarkan berbagi _format file_ tetapi tidak harus semua perilaku perangkat lunak itu sendiri.

bahwa ada sedikit upaya untuk masuk ke mode swarm sejak pengumuman dukungan K8

Penanganan file penulisan semuanya dilakukan di sisi klien, dan digunakan baik untuk k8s dan swarmkit, jadi tidak ada yang melambat di area ini, selain "hanya ada begitu banyak yang dapat kami lakukan pada waktu tertentu"

Bagi mereka yang menunggu fitur itu; rilis yang akan datang akan memiliki dukungan untuk beberapa file penulisan untuk docker stack deploy , jadi jika saat ini Anda menggunakan fitur itu dalam penulisan buruh pelabuhan: rilis buruh pelabuhan yang akan datang akan mendukung ini juga

Selain semantik, terima kasih atas pembaruannya. Ketika saya mengatakan Docker, yang saya maksud bukanlah daemon atau mesin, tetapi perusahaan yang membuat alat tersebut. Asal usul komentar tentang ada sedikit usaha benar-benar berasal dari fakta bahwa mode swarm telah keluar selama lebih dari setahun dan masih JAUH di belakang di mana kami berada dengan satu node menggunakan compose.

Saya dapat menghargai bahwa mereka berbeda, tetapi menggunakan format file yang sama, tetapi itu sebenarnya menyebabkan lebih banyak kebingungan, dan berpotensi mengecewakan, ketika pengguna menemukan bahwa mereka harus menukar fitur untuk menggunakan swarm. Itu dan fakta bahwa file DAB MASIH terdaftar sebagai eksperimental. Sayangnya, kami membuat keputusan untuk menggunakan mode swarm dalam proyek besar, atau saya tidak akan peduli. Untungnya, kami tidak akan membuat kesalahan itu lagi.

[sunting]

Jika variabel lingkungan disetel, docker slack deploy seharusnya sudah menginterpolasinya

Melakukan ini di lingkungan CI sangat merepotkan. Pada dasarnya, saya akhirnya menginstal compose, mencari sumber envvars, mencuci file penulisan (setelah menarik gambar) dan kemudian mengeluarkan file penulisan baru untuk digunakan dengan stack deploy . (Dan saya bahkan tidak akan memulai tentang betapa menyakitkannya ketika :latest tidak berarti :latest dalam mode swarm, karena masalah ini khusus tentang interpolasi variabel.)

_EDIT: Saya harap posting ini tidak tampil agresif. Saya menyukai konsep Docker Stack dan saya pikir seluruh suite Docker didukung dengan cukup baik. Sepertinya Docker (organisasi) saat ini tidak melihat produknya dengan cara yang sama seperti yang dilakukan pengguna, yang sangat disayangkan dan tampaknya menjadi penyebab sebagian besar masalah yang saya alami saat menggunakan Compose dan Stack._

Docker tidak pernah memiliki fitur ini; menulis buruh pelabuhan memiliki; docker compose dan docker stack menyebarkan berbagi format file tetapi tidak harus semua perilaku perangkat lunak itu sendiri.

Saya merasa pernyataan ini mengungkapkan keterputusan mendasar antara cara pengembang dan pengguna Docker melihat produk ini. Sebagai pengguna, baik saya bekerja dengan Docker Engine, Docker Compose, atau Docker Swarm, semuanya adalah Docker dan harus berperilaku secara konsisten sejauh mungkin.

Pemahaman saya tentang tujuan dari produk ini adalah:

• Mesin Docker adalah untuk membangun dan menjalankan kontainer individu
• Docker Compose adalah untuk menjalankan rangkaian kontainer dalam pengembangan
• Docker Stack adalah untuk menyebarkan kontainer ke produksi

Salah satu nilai jual utama Docker (dan container secara umum) adalah penggunaan kembali aplikasi yang sama dengan mudah di berbagai lingkungan. Oleh karena itu, Compose harus menjadi aditif untuk Engine dan Stack harus menjadi aditif untuk Compose. Terutama karena mereka berbagi format file yang sama, Stack yang tidak mendukung fitur Compose menyebabkan kebingungan bagi pengembang dan menambah kerumitan dalam proses CI.

Saya tidak akan mengatakan compose adalah untuk dev dan stack untuk prod, tentu saja. Saya melihat penulisan sebagai untuk aplikasi multi-wadah atau "sistem" dan tumpukan untuk penyebaran multi-Host menggunakan mode swarm sebagai penjadwal/orkestrator. Jika tidak, komentar Anda 100% tepat. Saya juga frustrasi (jika tidak jelas dengan komentar saya yang lain) bahwa ada keterputusan antara pengembang dan pengguna tentang bagaimana produk digunakan.

Oh wow. Saya bergabung dengan kebingungan dan rasa sakit saat mengevaluasi kawanan buruh pelabuhan untuk proyek besar juga.
Rahasia semuanya menyenangkan dan permainan, hanya saja tidak semua gambar buruh pelabuhan eksternal mendukung membaca rahasia dari file. Saya tidak ingin memodifikasi untuk masing-masing dan menempatkan gambar khusus. Mungkin menggunakannya untuk proyek saya, ya, tetapi untuk proyek eksternal tidak boleh.
Sehingga meninggalkan variabel env. Tapi hei, mereka berperilaku berbeda dari menulis ke tumpukan! Bayangkan keterkejutan saya ketika saya perhatikan bahwa mereka tidak benar-benar berfungsi.
Bagaimana mungkin memiliki tumpukan buruh pelabuhan tanpa dukungan env? yang terbaik menurut saya --env-file=dev.env , jadi itu tidak akan mengganggu file env lainnya ... tetapi dukungan untuk ini mengerikan. Sayangnya saya harus kembali ke k8s, karena tumpukan yang melewatkan ini sejak awal, dapat terbukti menjadi pilihan yang mengerikan saat dalam produksi, siapa yang tahu berapa banyak hal lain yang akan hilang.

Sudah dua tahun dan kita masih seperti itu... Aku tidak ingin terlihat kasar, tapi ayolah! Ini masalah menggunakan kembali sedikit kode dari docker-compose!

Masalah serupa lainnya yang baru saja saya alami adalah bahwa meskipun Anda menggunakan env_file, perilakunya masih tidak persis sama.

Saya menggunakan env_file untuk memuat jalur yang ditentukan dari root proyek, tetapi file penulisan saya berada di subdirektori yang berbeda. Untuk meluncurkan dengan docker-compose, saya hanya menggunakan --project-directory . -f path/ke/docker-compose.yml

docker stack tidak mengizinkan saya untuk menentukan direktori proyek, menyebabkan semua env_file saya gagal dimuat.

Mengubah env_file menjadi "../../path/to/envrc" tidak berfungsi dengan docker-compose, karena file-file ini harus berada di dalam direktori root proyek

+1

+1

+1 ini akan sangat berguna. Tidak melihat sisi negatifnya sebenarnya.

Sangat bodoh bahwa buruh pelabuhan belum mendukung ini.

+1 @joao-fidalgo Itu pasti.

+1

Baru saja mengalami hal yang sama saat kami mencoba swarm. Saya telah membaca semua pesan di berbagai utas dan saya merasa sangat frustrasi. IMO, beberapa poin yang sangat bagus dan argumen yang kuat dibuat oleh @ntwrkguru dan lainnya. Saya harap kami dapat mempertimbangkan mereka untuk memasukkan fitur ini; hacks tidak akan memotongnya.

.env file

export MYSQL_USER=user

source .env && docker stack deploy

Ini juga akan bekerja dengan docker-compose up untuk bash

.env file

export MYSQL_USER=user

source .env && docker stack deploy

Ini juga akan bekerja dengan docker-compose up

Itu hanya akan berfungsi untuk bash dan bukan shell lainnya.

Ini membuatku bingung seperti orang gila. Aplikasi saya akan muncul menggunakan komposisi buruh pelabuhan, tetapi tidak dengan penyebaran tumpukan buruh pelabuhan. Setidaknya harus ada penafian yang ditampilkan dengan jelas di dokumen

Tapi IMO ini adalah bug, dan menurunkan pengalaman buruh pelabuhan.

Kami membutuhkan jawaban tentang ini

Hampir 2 tahun dan tidak ada yang mengambilnya ... jangan menahan napas @jorgelimafeitosa

Saya tidak berpikir CLI akan menambahkan dukungan .env . Perintah docker stack deploy awalnya dibuat dengan mempertimbangkan file Bundel Aplikasi Terdistribusi (karenanya opsi --bundle-file ). File DAB dihasilkan oleh Docker Compose dengan perintah docker-compose bundle . .env dan fitur Compose lainnya akan ditangani oleh docker-compose , sebelum diteruskan ke docker stack deploy . Dukungan langsung untuk file Compose di docker stack deploy selalu lebih merupakan kompromi.

Janji asli file DAB sekarang hidup di Aplikasi Docker, yang juga tidak memproses .env .

Saya meminta pengembang saya menggunakan docker-compose config untuk melakukan pra-proses proyek Docker Compose sebelum meneruskannya ke docker stack deploy . Anda dapat melakukan ini dalam satu baris dengan:

docker stack deploy -c <(docker-compose config) stack-name-here

Dengan begitu, semua fitur Docker Compose termasuk pemrosesan .env diterapkan sepenuhnya.

@kinghuang Mencoba solusi Anda, tetapi tidak berhasil. "docker-compose config" menghasilkan output yang benar di direktori yang sama, tetapi "docker stack deploy -c docker-compose.yaml my_stack" tidak akan menggantikan variabel dari .env. Apa yang saya lewatkan? Ini adalah versi Docker 18.09.0, membangun 4d60db4.

@kinghuang Mencoba solusi Anda, tetapi tidak berhasil. "docker-compose config" menghasilkan output yang benar di direktori yang sama, tetapi "docker stack deploy -c docker-compose.yaml my_stack" tidak akan menggantikan variabel dari .env. Apa yang saya lewatkan? Ini adalah versi Docker 18.09.0, membangun 4d60db4.

docker stack deploy -c <(docker-compose -f docker-compose-frpc-swarm-traefik.yml config) traefik

@kinghuang

buka /dev/fd/63: tidak ada file atau direktori seperti itu

PERINGATAN: Beberapa layanan (project1, project2) menggunakan kunci 'deploy', yang akan diabaikan. Compose tidak mendukung konfigurasi 'deploy' - gunakan docker stack deploy untuk men-deploy ke swarm.

@kinghuang
Hanya lingkungan root yang tidak akan melaporkan kesalahan.

Mendukung .env dan env_file tidak selalu masuk akal dalam lingkungan penerapan/produksi. Anda tidak memerlukan akses langsung ke sistem file untuk fitur lain dari Docker Swarm. Jadi, perancang/operator yang bertanggung jawab dari sistem itu tidak akan mau memberi Anda kemampuan untuk membuang file lingkungan ke sistem file.

Secara teoritis Swarm dapat mendukung pemuatan rahasia ke lingkungan secara otomatis tetapi lihat https://github.com/moby/moby/issues/30866#issuecomment -278924983 untuk alasan mengapa itu mungkin bukan ide yang baik dari segi keamanan.

Yang dapat Anda lakukan hari ini adalah menggunakan rahasia dan memuatnya ke dalam lingkungan aplikasi Anda saat penampung berjalan. Itu memberi Anda kendali atas di mana nilai-nilai lingkungan rahasia dapat dilihat.

+1
penyebaran tumpukan buruh pelabuhan harus benar-benar mendukung --env-file.
Saya sendiri kesulitan menggunakan kembali file .yml yang sama untuk menyebarkan tumpukan yang berbeda untuk lingkungan pengembangan/pengujian/produksi dan saya tidak ingin berurusan dengan beberapa ekspor/sumber variabel lingkungan yang rumit sebelum menyebarkan tumpukan. Ini sangat rawan kesalahan (dan menyebalkan juga untuk mengingat perintah yang tepat setiap kali).
Dalam kasus khusus saya, misalnya, saya ingin menetapkan nama indeks yang berbeda (elasticsearch) per lingkungan - tetapi konfigurasi lainnya tetap sama. Ini tidak ada hubungannya dengan "rahasia" seperti yang disebutkan dalam posting sebelumnya.
Tampaknya ada kebutuhan nyata untuk --env-file untuk penyebaran tumpukan buruh pelabuhan berdasarkan riwayat komentar di atas, tetapi sayangnya pengembang Docker tampaknya tidak melihatnya.

Di lingkungan swarm saya, saya menetapkan beberapa solusi:

• rahasia/konfigurasi, yang saya gunakan untuk memuat file konfigurasi dan sertifikat.
• Setelah menonton demo lingkungan pengembangan Azure di mana mereka memiliki skrip interpolasi variabel yang mereka jalankan sebelum mengirimkan file penulisan, saya menulis sendiri yang saya masukkan ke dalam alur rilis GitLab saya.

Cukup tentukan file .env di docker-compose.yml Anda dan itu berfungsi:

env_file:
  - .env

Lihat https://stackoverflow.com/questions/44694640/docker-swarm-with-image-versions-externalized-to-env-file

Sebuah solusi di PowerShell untuk digunakan di windows untuk mengurai file .env sebelum memanggil buruh pelabuhan:

switch -regex -file "./.env" { "^\s ([^#].+?)\s =\s (. )" { $name,$value = $matches[1..2]; Set-Item "env:$name" $value}}

Sangat terinspirasi oleh parsing file .ini: https://stackoverflow.com/questions/417798/ini-file-parsing-in-powershell

Solusi lain adalah: set -a && . .env && set +a && docker stack deploy... .

Ini konyol. Saya hanya menghabiskan sepanjang hari mencoba untuk mendapatkan ini untuk bekerja. Penafian setidaknya diperlukan di suatu tempat di dokumen yang .env tidak dibaca oleh perintah docker stack .

@cjancsar Mereka melakukannya. Dokumentasi mengatakan:

Penting: Fitur file .env hanya berfungsi saat Anda menggunakan perintah penulisan buruh pelabuhan dan tidak bekerja dengan penyebaran tumpukan buruh pelabuhan

Di luar minat. Apa yang saat ini dilakukan orang ketika dalam mode swarm, dan mereka ingin memperbarui gambar buruh pelabuhan yang baru dibuat, misalnya ap plication:v1 ke ap plication:v2 , layanan yang sama (tidak ada lagi yang berubah)?

Inilah alasan saya datang ke masalah ini. Makanya saya tertarik.

Saat ini di docker-compose, mudah untuk mendapatkan otomatisasi untuk berinteraksi dengan file yang tidak dilacak kontrol sumber . env untuk memperbarui versi gambar, lalu docker-compose up -d

Seringkali saya menggunakan komit sha sebagai versi gambar buruh pelabuhan untuk penyebaran 'pementasan' (tag git digunakan untuk rilis aktual setelah siklus pengujian yang memadai), jadi sebenarnya tidak mungkin untuk mengkomit versi gambar baru ke kontrol sumber.

Apakah mungkin untuk memperbarui rahasia buruh pelabuhan (meskipun itu sebenarnya bukan rahasia) sebagai solusinya? Apakah itu yang dilakukan orang, atau ada hal lain yang dilakukan.

Saya meminta pengunjung masa depan dari masalah ini, sehingga mereka benar-benar datang dengan praktik terbaik saat ini, karena fungsionalitas yang mereka cari belum (belum?) ada.

Hai, Saya sibuk mencari penyebaran tumpukan untuk digunakan dalam pipa CI/CD, dapat menggunakan file .env akan sangat berguna, ada umpan balik apakah opsi ini akan diperkenalkan pada tahap apa pun?

Tampaknya rekomendasi resmi adalah, memang, untuk memigrasikan kode gambar Anda untuk mendukung membaca jenis variabel ini dari file teks rahasia ± mempertahankan kemampuan untuk juga membaca ini dari variabel lingkungan untuk kompatibilitas mundur non-stack/swarm.

Contoh ini menggunakan satu rahasia per file teks, yang menghindari keharusan mengurai file .env lama.

Diparafrase dari dokumentasi di https://docs.docker.com/engine/swarm/secrets/#use -secrets-in-compose :

services:
   db:
     image: mysql:latest
     environment:
       MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD_FILE: /run/secrets/db_password
     secrets:
       - db_root_password
       - db_password

secrets:
   db_password:
     file: db_password.txt
   db_root_password:
     file: db_root_password.txt

mendesah

Ini harus lebih jelas dalam dokumentasi. Meskipun disebutkan bahwa .env tidak didukung di bagian Substitusi Variabel per @lengxuehx , tidak disebutkan bahwa env_file diabaikan untuk penyebaran tumpukan.

Saya dapat mengonfirmasi bahwa solusi yang diusulkan oleh @kinghuang berfungsi dan tidak mengecualikan kunci penerapan seperti yang dikatakan seseorang.

docker stack deploy -c <(docker-compose config) stack-name-here

Ini harus lebih jelas dalam dokumentasi. Meskipun disebutkan bahwa .env tidak didukung di bagian Substitusi Variabel per @lengxuehx , tidak disebutkan bahwa env_file diabaikan untuk penyebaran tumpukan.

Saya dapat mengonfirmasi bahwa env_file digunakan dan berfungsi untuk menyebarkan perintah stack, persis seperti yang dilakukan oleh docker compose.

docker version
Client: Docker Engine - Community
 Version:           19.03.4
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        9013bf5
 Built:             Thu Oct 17 23:44:48 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.4
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.10
  Git commit:       9013bf5
  Built:            Thu Oct 17 23:50:38 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Untuk meringkas, untuk orang-orang seperti saya, yang telah membaca ini sejauh ini:

• docker stack deploy mendukung "Substitusi Variabel" tetapi Anda perlu mengatur variabel lingkungan dari file .env dengan cara tertentu. Beberapa opsi telah dijelaskan di atas. Salah satu solusi paling rapi adalah menggunakan docker-compose config sebagai pra-prosesor.
  Jadi Anda dapat membuat tumpukan Anda dengan docker stack deploy -c <(docker-compose config) STACK_NAME .
• Meskipun Docker memperkenalkan kemampuan konfigurasi dan rahasia , mereka memiliki kasus penggunaannya tetapi tidak akan melakukan hal yang sama seperti "Substitusi Variabel".
• Parameter env_file dalam file docker-compose.yml akan mengatur variabel lingkungan dalam wadah yang dibuat dan bukan pada file docker-compose.yml itu sendiri (dan karenanya tidak dapat digunakan sebagai alternatif untuk " Substitusi Variabel").

Memperbarui:

Saya dikoreksi oleh @thaJeztah.

Docker tidak mendukung Substitusi Variabel menggunakan penyebaran tumpukan buruh pelabuhan, dan solusi yang diusulkan tidak berfungsi.

docker stack deploy mendukung substitusi variabel, tetapi tidak mengevaluasi file .env ; dalam contoh di bawah ini, HELLO_VERSION disetel ke linux , dan layanan akan menggunakan tag hello-world:linux (sebagai ganti default hello-world:latest )

HELLO_VERSION=linux docker stack deploy -c docker-compose.yml mystack
Creating network mystack_default
Creating service mystack_hello

docker service inspect --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}' mystack_hello
hello-world:linux<strong i="14">@sha256</strong>:d073a5775c0b99d653c413161a8ed0e9685061afe697931d30eddf6afeef40f6

Meskipun demikian, Anda masih dapat menggunakan variabel lingkungan menggunakan parameter env_file di file docker-compose.yml Anda

env_file memiliki tujuan yang berbeda (dan setara dengan docker run --env-file ); opsi env_file menentukan env-vars apa yang akan diatur pada wadah yang dibuat, tetapi tidak digunakan dalam file penulisan itu sendiri (dan tidak digunakan untuk mengganti variabel dalam file penulisan sebelum menggunakan tumpukan).

Saya memiliki masalah yang sama di sepanjang sedikit perbedaan antara komposisi buruh pelabuhan dan tumpukan buruh pelabuhan.
Saya akhirnya membuat https://github.com/egyel/dcsh script/tool ​​untuk menangani masalah ini dengan pipa.

Halo semuanya, ini membantu saya menempatkan env_file di docker-compose saya:

env_file: /path/to/env/file
bukan

env_file:
  - /path/to/env/file

saya baru saja melihat ini dari posting lain dan saya hanya bisa berspekulasi mengapa ini berhasil (sama dengan spekulasi Anda) tetapi kami memerlukan konfirmasi mengapa ini berfungsi sebagai buruh pelabuhan yang disebutkan secara eksplisit dalam dokumen bahwa env_file tidak berfungsi.

Pemahaman saya adalah bahwa file env tidak dapat digunakan untuk mengisi placeholder di
file docker-stack.yml tetapi masih dapat diberikan ke container.
Perhatikan bahwa apa yang Anda lakukan tidak memungkinkan Anda untuk mengatur nama gambar dari
file env misalnya.

Pada Minggu, 17 Mei 2020, 06:08 raphyphy [email protected] menulis:

[gambar: gambar]
https://user-images.githubusercontent.com/30310576/82135555-a1e4be00-9836-11ea-9df4-a1b82e014b0e.png
Halo semuanya, ini membantu saya menempatkan env_file di docker-compose saya:

env_file: /path/ke/env/file
bukan

file_env:

• /path/ke/env/file

saya baru saja melihat ini dari posting lain dan saya hanya bisa berspekulasi mengapa ini berhasil
(sama seperti spekulasi Anda) tetapi kami membutuhkan konfirmasi mengapa ini terjadi
bekerja sebagai buruh pelabuhan yang secara eksplisit disebutkan dalam dokumen bahwa env_file tidak
bekerja.

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

Solusi komposisi buruh pelabuhan yang disebutkan di atas:

docker stack deploy -c <(docker-compose config) stack-name-here

memiliki kelemahan (bagi saya) bahwa hal-hal seperti file .env dan, terutama, file docker-compose.override.yml biasanya lebih merupakan bagian dari lingkungan pengembangan saya. Saya tidak benar-benar ingin mereka dibawa saat digunakan untuk produksi.

Saya akhirnya memiliki docker-compose-production.yml terpisah di mana saya mengendalikan berbagai hal dengan hati-hati, meskipun itu melibatkan beberapa duplikasi.

Saya tidak berpikir CLI akan menambahkan dukungan .env . Perintah docker stack deploy awalnya dibuat dengan mempertimbangkan file Bundel Aplikasi Terdistribusi (karenanya opsi --bundle-file ). File DAB dihasilkan oleh Docker Compose dengan perintah docker-compose bundle . .env dan fitur Compose lainnya akan ditangani oleh docker-compose , sebelum diteruskan ke docker stack deploy . Dukungan langsung untuk file Compose di docker stack deploy selalu lebih merupakan kompromi.

Janji asli file DAB sekarang hidup di Aplikasi Docker, yang juga tidak memproses .env .

Saya meminta pengembang saya menggunakan docker-compose config untuk melakukan pra-proses proyek Docker Compose sebelum meneruskannya ke docker stack deploy . Anda dapat melakukan ini dalam satu baris dengan:

docker stack deploy -c <(docker-compose config) stack-name-here

Dengan begitu, semua fitur Docker Compose termasuk pemrosesan .env diterapkan sepenuhnya.

Ini berfungsi seperti pesona, perlu diingat jika file penulisan Anda tidak memiliki nama "docker-compose.yml" perintah Anda harus menyertakan nama file penulisan yang sebenarnya.

docker stack deploy -c <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config) CUSTOM-STACK

HATI -HATI HACK <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config !!! Output dari docker-compose config dan docker-compose -f myfile.yml config TIDAK harus sama! Yang terakhir terkadang membungkus variabel env dalam tanda kutip tambahan, sehingga hasilnya akan salah!

Contoh:

environment:
  SERVER_URL: '"xxx"'

dari pada

environment:
  SERVER_URL: xxx

Apakah masalah ini sudah dilacak di suatu tempat?