لاختبار وظيفة docker stack deploy --compose-file
، قمت بتحميل إحدى عيّناتي docker-compose.yml
:
version: '3'
services:
nginx:
image: "${DOCKER_USER}/lnmp-nginx:v1.2"
build:
context: .
dockerfile: Dockerfile.nginx
ports:
- "80:80"
networks:
- frontend
depends_on:
- php
php:
image: "${DOCKER_USER}/lnmp-php:v1.2"
build:
context: .
dockerfile: Dockerfile.php
networks:
- frontend
- backend
environment:
MYSQL_PASSWORD: Passw0rd
depends_on:
- mysql
mysql:
image: mysql:5.7
volumes:
- mysql-data:/var/lib/mysql
environment:
TZ: 'Asia/Shanghai'
MYSQL_ROOT_PASSWORD: Passw0rd
command: ['mysqld', '--character-set-server=utf8']
networks:
- backend
volumes:
mysql-data:
networks:
frontend:
backend:
في قسم image
للخدمة nginx
و php
، استخدمت ${DOCKER_USER}
للحصول على معرّف عامل الإرساء من متغيرات البيئة. وإذا استخدمت docker-compose up
، فسيتم تحميل ملف .env
كملفات envvar افتراضية ، ما المحتوى هو:
DOCKER_USER=twang2218
ومع ذلك ، إذا استخدمت docker stack
لنشر هذا docker-compose.yml
، فسوف أتلقى الأخطاء التالية:
$ docker stack deploy --compose-file docker-compose.yml lnmp
Ignoring unsupported options: build
Creating network lnmp_frontend
Creating network lnmp_backend
Creating network lnmp_default
Creating service lnmp_php
Error response from daemon: rpc error: code = 3 desc = ContainerSpec: "/lnmp-php:v1.2" is not a valid repository/tag
كما ترى ، نظرًا لأن الأمر docker stack deploy
لم يقم بتحميل ملف .env
، فقد تم استبدال ${DOCKER_USER}
بسلسلة فارغة ، مما أدى إلى عدم صلاحية اسم الصورة.
إذا تم تحميل ملف .env
، فيجب أن يكون اسم الصورة النهائي twang2218/lnmp-php:v1.2
.
يعمل استبدال البيئة بالفعل ، إذا قمت بتشغيل الأمر بهذه الطريقة:
$ DOCKER_USER=twang2218 docker stack deploy --compose-file docker-compose.yml lnmp
Ignoring unsupported options: build
Creating network lnmp_frontend
Creating network lnmp_backend
Creating network lnmp_default
Creating service lnmp_mysql
Creating service lnmp_nginx
Creating service lnmp_php
ويمكننا التحقق من أنه يعمل عن طريق الأمر docker service inspect
:
$ docker service inspect lnmp_php | grep Image
"Image": "twang2218/lnmp-php:v1.2<strong i="13">@sha256</strong>:4f1aef1350aeef3f757f6b6da8f2e1a79ff849f61382320e4b668bfe2b0d1c5a",
اسم الصورة هو twang2218/lnmp-php:v1.2
، وهذا صحيح.
لقد اختبرت هذه الميزة على Digtial Ocean droplet ، الذي قام بتثبيت عامل الإرساء 1.13.0-rc2 عبر docker-machine
.
ها هو الإصدار:
$ docker version
Client:
Version: 1.13.0-rc2
API version: 1.25
Go version: go1.7.3
Git commit: 1f9b3ef
Built: Wed Nov 23 06:32:39 2016
OS/Arch: linux/amd64
Server:
Version: 1.13.0-rc2
API version: 1.25
Minimum API version: 1.12
Go version: go1.7.3
Git commit: 1f9b3ef
Built: Wed Nov 23 06:32:39 2016
OS/Arch: linux/amd64
Experimental: false
هذا هو docker info
:
root<strong i="25">@d1</strong>:~/docker-lnmp# docker info
Containers: 7
Running: 1
Paused: 0
Stopped: 6
Images: 4
Server Version: 1.13.0-rc2
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 43
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: active
NodeID: vyf3mgcj3uonrnh5xxquasp38
Is Manager: true
ClusterID: jb8rxvd6ptrn3psfkiixxed7r
Managers: 1
Nodes: 3
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: 138.197.195.206
Manager Addresses:
138.197.195.206:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 51371867a01c467f08af739783b8beafc154c4d7
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-51-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 488.5 MiB
Name: d1
ID: E6UB:PHX6:I2KY:Q35T:PCCI:MFDQ:ZMMN:2X7K:DEOZ:PAP7:4BUC:FP6X
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
provider=digitalocean
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
هذا حسب التصميم. يعد الدعم .env
إحدى ميزات "الإنشاء" ، وليس تنسيق الملف.
يمكننا مناقشة إضافة هذا لإصدار مستقبلي ، لكني لا أعرف ما إذا كان هذا هو الخيار الأفضل حقًا.
يعد دعم .env
مفيدًا جدًا في الإنشاء ، فقد استخدمناه في العديد من ملفات الإنشاء. يفصل بين الأجزاء الديناميكية والأجزاء الثابتة لملف docker-compose.yml
. من خلال تحميل .env
افتراضيًا ، يمكننا فقط توفير ملف .env
مختلف لبيئات مختلفة ، والحفاظ على docker-compose.yml
والنصوص ذات الصلة ثابتة.
لا يمكن استخدام env_file
أو environment
في docker-compose.yml
لتحقيق نفس نتيجة الاستبدال envvars. .env
أسهل طريقة للقيام بذلك.
بخلاف ذلك ، يتعين علينا إضافة البادئة export
في كل سطر من ملف .env
يدويًا source .env
في كل مرة قبل تحميل docker-compose.yml
، والخطوات الإضافية تكون عرضة أحيانًا يخطئ.
لقد لاحظت هذا للتو.
افترضت / توقعت أن يعمل بنفس الطريقة التي يعمل بها مع Compose ، ولكن ليس هذا هو الحال بالنسبة لـ docker deploy
.
في حالتي الخاصة ، كنت أتوقع استخدام ملف .env
لتخزين البيانات الحساسة (كلمات المرور ، مفاتيح API ، إلخ) المستخدمة في الخدمات التي سأقوم بإنشائها في المكدس:
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
أثناء إيداع ملف الإنشاء هذا على Git ، سيتم تجاهل ملف .env
.
لقد تابعت كل العناصر / سجل ملفات * .dab vs compose ، وأشعر أنكم تحاولون تجنب شيء ما - أو اقتراح حل أفضل - لكنني فقدت مسار المناقشة بأكملها ...
اهلا جميعا،
إصدار عامل السفن: v1.13.0-rc4.0
يظهر لي خطأ: تجاهل الخيارات غير المدعومة: إنشاء ، هل هذا يعني أنه لن يتم إنشاء بنية من Dockerfile؟
وأيضًا الحصول على نفس الخطأ في وضع_الشبكة: تجاهل الخيارات غير المدعومة: وضع_الشبكة.
أدناه هو الأمر:
DOCKER_IMAGE = نشر مكدس عامل الإرساء akhil123 -c docker-compose.yml foo
شكرا كثيرا مسبقا.
akhildangore يرجى عدم التعليق على المشكلات المتعلقة بالأسئلة التي لا تتعلق مباشرة. ميزة docker stack deploy
_ by design_ لا تؤدي عمليات الإنشاء. والسبب في ذلك هو تنفيذ _build_ على المضيف الذي يتم تشغيل الأمر منه ، وبالتالي لن تكون الصورة متاحة إلا على العقدة _that_. عند نشر تلك الصورة في Swarm ، لا يمكن بدء الخدمة على العقد الأخرى. لنشر الخدمات ، تأكد من دفع الصورة التي تنشرها إلى السجل (أو للاختبار ؛ تأكد من توفر الصورة على كل عقدة في السرب)
هل هناك أي قضايا / مناقشة لصالح / ضد دعم هذا السلوك على docker deploy
؟
vovimayhem لم يتم اتخاذ قرار بعد بشأن ملف .env
، ولكن قد تكون مهتمًا بـ https://github.com/docker/docker/pull/30144 ، والذي يضيف دعمًا للأسرار إلى ملف الإنشاء
لقد وجدت هذه المناقشة للتو. ممتاز!
أنا أستخدم وظيفة bash كحل بديل.
يمكنك تكييفها مع احتياجاتك حتى يتم إصدار ميزة secrets
:
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
)
}
للمشتركين في هذه القضية ؛ سيتم تضمين دعم الأسرار لملفات إنشاء عامل الإرساء في الإصدار 1.13.1 ، والذي يجب ألا يكون بعيدًا جدًا في المستقبل
whoan أنا أستخدم هذا كحل بديل:
env $(cat .env | grep ^[A-Z] | xargs) docker stack deploy --compose-file docker-compose.yml [STACK_NAME]
بهذه الطريقة ، لا تتعطل المتغيرات في نافذة المحطة
من الجيد دائمًا أن تكون لديك القدرة على تحميل الأشياء من ملف .env
- بصرف النظر عن حالة استخدام أسرار Docker الأبسط التي يمكن التحايل عليها الآن ، هناك دائمًا قيم Docker Compose التي لا تريد ترميزها بشكل ثابت في الريبو الخاص بك.
لنفترض أنك تستخدم docker stack deploy
لنشر مكدس كامل ولديك المتطلبات التالية:
إذا لم تتمكن من تكوين هذا باستخدام ملف .env
، فأنت بحاجة إلى تغيير ملف docker-compose.yml
يدويًا قبل نشر المكدس في كل مرة ، وإلا ستعود قيمة مقياس الخدمة إلى 1.
يمكنك تمديد ما سبق بأشياء مثل الشبكات ، وتكوين DNS الذي يجب أن تستمع إليه الخدمة ، وما إلى ذلك.
يمكنني صياغة مسودة PR من شأنها تحميل ملف .env
، إذا كان أحدهما موجودًا في نفس الدليل مثل docker-compose.yml
إذا كنا نعتقد أن حالات الاستخدامات المذكورة أعلاه منطقية.
يختلف تصميم نشر docker stack
قليلاً عن أوامر docker-compose
. لا أعتقد أنه من المنطقي قراءة .env
افتراضيًا. لا تتم قراءة docker-compse.yml
بشكل افتراضي ، لأنه في المستقبل من المحتمل أن يكون مصدر النشر الافتراضي شيئًا آخر.
يمكنك دائمًا الحصول على ملف .env
بنفسك قبل تشغيل stack deploy
.
فقط . .env
قبل استدعاء docker stack deploy
لا يساعد ، لا يتم استبدال المتغيرات $. ساعدت خدعة env .. xargs
فقط.
سيكون من الجيد أن يكون لديك خيار --env-file=FILE
مثل docker run
.
فقط . env قبل استدعاء نشر كومة عامل ميناء لا يساعد
من المفترض أن يساعد هذا @ C-Pro - يجب أن يكون لديك خطوط export ...
في ملف .env
. بدلاً من ذلك ، يمكنك عمل export $(cat .env)
، والذي سيعمل في معظم الحالات.
اهلا جميعا،
حاولت اليوم تشغيل docker stack deploy
.
ملفي docker-compose.yml
:
version: '3'
services:
simple:
image: alpine
environment:
- FOO: ${BAR}
env_file: .env
وملف .env
في نفس الدليل:
BAR=worked
بعد إطلاق docker stack deploy -c docker-compose.yml test
، فتشت الحاوية وحصلت على هذا:
$ env
BAR=worked
FOO=
...
يبدو أن .env
مقدم في الحاوية ، لكن لم يتم توفيره على الجهاز المضيف.
هذا يعني أنه يمكنني استخدام ملف .env
بدلاً من قسم environment
، لكن لا يمكنني استخدام ملف .env
مع استبدال المتغير.
إصدار عامل ميناء: v17.03
تضمين التغريدة
بيئة:
- FOO = $ {BAR}
يبدو أن ملف env هذا يعمل فقط للحاوية ، ولكن ليس لاستبدال متغير ملف docker-compose.yml.
Docker for MAC ، Docker الإصدار 17.03.1-ce ، بناء c6d412e
تضمين التغريدة
نعم. ولكن لاستخدام متغيرات ملف .env
داخل الحاوية ، يجب عليك إزالتها في قسم environment
.
فمثلا:
عامل ميناء compose.yml
...
environment:
- FOO=${FOO:-empty}
...
.env
FOO=filled
في الحاوية حصلت على هذا:
$ env
FOO=empty
ولكن إذا قمت بإزالة FOO
من environment
قسم في docker-compose.yml
، فقد حصلت على هذا:
$ env
FOO=filled
تضمين التغريدة
تتجاوز متغيرات البيئة المحددة في البيئة هذه القيم المحددة في ملف env.
dnephin : لقد ذكرت أن .env ليس جزءًا من تنسيق ملف إنشاء عامل الإرساء. ومع ذلك ، يتم توثيق ميزة ملف .env في مرجع الإصدار 3 من إنشاء ملف: https://docs.docker.com/compose/compose-file/#variable -substitution.
هذا يعطي الانطباع أن .env أيضًا يجب أن يعمل مع نشر مكدس عامل الإرساء.
إلى جانب ذلك ، كما ذكر آخرون بالفعل ، فإن فصل القيم المحددة للبيئة الفعلية عن تعريف المكدس yaml هو ميزة مطلوبة / مطلوبة بشدة. على وجه التحديد ، نريد استخدامه لتحديد إصدارات الصور ومضاعفاتها.
شكرًا ، فتحت https://github.com/docker/docker.github.io/issues/3654 لإصلاح المستندات
يمكن أن يأخذ docker stack deploy
ملفًا تم إنشاؤه. هذا يعمل في bash لجميع متغيراتي ويحافظ على سرية الأسرار أيضًا:
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
يرجى ملاحظة أنني أضفت متغيرات ENV المضمنة كمتغيرات إضافية أو تجاوزات. تشير ملفات الإنشاء الخاصة بي إلى ملفات .env وهذا يعمل. أتمنى أن يكون هذا مفيدًا 👍
وظيفة docker-compose config
هي ما يربط هذا معًا.
لقد صادفت هذه المشكلة عند البحث عن حل لمشكلتي .env
التي لم تتم قراءتها بواسطة docker stack deploy
. لقد فوجئت قليلاً برؤية أنه لم يتم دعمه (يمكن توضيح المستندات) ، لكنني أريد إضافة دعمي لـ .env
، مثل الإنشاء.
حالة الاستخدام الخاصة بي هي أنني أستخدم docker stack deploy
في بيئات التطوير والاختبار والتشغيل المرحلي واستخدام متغيرات البيئة لخيارات المكدس للحفاظ على ملف yml كما هو.
حاليًا باستخدام أحد الحلول المنشورة هنا ولكن استخدام ملف .env
سيكون المسار المفضل.
مجرد تذكير سهل: قد يكون هناك احتمال أن تحاول استخدام ملفات dotenv لتخزين مفاتيح API وكلمات المرور والأشياء الأخرى التي تعتبر "حساسة" لوضعها في المجموعة. في هذه الحالات ، يجب أن تستخدم Docker Secrets .
بالنسبة للأشياء الأخرى ، هل يمكنني اقتراح ملف إنشاء واحد لكل بيئة منشورة / قابلة للنشر؟ ستكون معظم الأشياء التي تتغير بين البيئات المختلفة هي الخوادم المتاحة ، وتنظيم الخادم المختلف ، وما إلى ذلك ... وبالتالي تحتاج إلى قيم مختلفة في محتويات المفتاح deploy
(قواعد placement
، resources
للحجوزات ، وما إلى ذلك) ، مما يجعل استخدام ملف واحد لكل شيء معقدًا بعض الشيء.
في الواقع أريد هذه الميزة ، يمكن التعامل مع المتغيرات في ملف الإنشاء كقيمة مختلفة على مضيف مختلف عند استخدام نشر مكدس عامل الإرساء.
"بالنسبة للأشياء الأخرى ، هل لي أن أقترح وجود ملف إنشاء واحد لكل بيئة منشورة / قابلة للنشر؟ ستكون معظم الأشياء التي تتغير بين البيئات المختلفة هي الخوادم المتاحة ، وتنظيم الخادم المختلف ، وما إلى ذلك ... وبالتالي تحتاج إلى قيم مختلفة على مفتاح النشر المحتويات (قواعد التنسيب ، حجز الموارد ، إلخ) ، مما يجعل استخدام ملف واحد لكل شيء أمرًا معقدًا للغاية ".
vovimayhem آسف لكونك صريحًا ، لكن هذا لا يبدو منطقيًا مثل استخدام ملف تكوين واحد مع استبدال متغير باستخدام env_file. أفضل استخدام تنسيق env_file لأن هذا يجعل الأمر أسهل بكثير بالنسبة لي لتقديم مكدسات كتوصيل لعملائي وتدريبهم على تحديث ملفات vars بنمط ini واحد بدلاً من العبث بملف مؤلف (وهو ما لم أفعله. 'تي تريد).
تعد تكوينات الخدمة إضافة رائعة ، لكنها لا تبدو قابلة للاستخدام لاستيفاء وقت النشر (مثل $ TAG).
إذا كانت متغيرات البيئة مدعومة على الإطلاق ، فكن متسقًا في الآليات المستخدمة لحلها عبر الأدوات. يبدو أن نشر Stack يختار عدم الاتساق ، دون تغيير السلوكيات المتغيرة للبيئة بشكل أساسي. تعد الأسرار وتكوينات الخدمة بدائل أفضل لبعض استخدامات متغيرات البيئة ، لكنها لا تستوعب.
لا يبدو أنك تحصل عليهvovimayhem. أنا لا أتحدث عن تمرير الأنابيب إلى الحاويات ؛ يعمل كما هو متوقع. ما أعنيه هو استخدام env_file الذي تم تحليله خلال stack deploy
كما كان خلال compose up
.
ntwrkguru لقد اعتقدت للتو أن هذه الميزة الجديدة ستساعدك ... أنا حزين جدًا لأنها لا تفعل ذلك.
هذا لا يزال يعمل كبديل.
$ 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 ، إنه كذلك بالفعل. لدي مهمة في كتيب التشغيل الخاص بي لمصدر ملف بيئات ، لكن هذا يفتقد إلى النقطة الأكبر. كان هذا ممكنًا مع compose
وهو غير ممكن الآن مع stack
. IMO ، هذا انحدار. أيضًا ، في مثالك ، ما زلت تمرر متغير بيئة في الحاوية. يمكنني فعل ذلك مع env_files
اليوم ؛ المشكلة هي تحليل env_file
أثناء عملية stack deploy -c docker-compose.yml
.
هذا مؤلم بشكل خاص لأن stack
لم يعد يدعم ملفات إنشاء متعددة ، وإلا يمكن للمرء ببساطة استخدام ملف إنشاء ثانوي لكل بيئة. للقيام بذلك ، يتطلب الأمر إنشاء ملف مكدس من ملفات الإنشاء ، وتقديم خطوة أخرى. لذلك ، في كلتا الحالتين ، انتقلنا من عملية من خطوة واحدة إلى عملية متعددة الخطوات لتحقيق نفس النتيجة النهائية.
أيضًا ، FWIW ، configs
هو حقًا أقل من المتوسط في تجربتي للتكوينات الفعلية. كنت أتخيل (آمل) أن يكون لديّ مصدر /application/config.conf
. قم بتحديث هذا الملف والتنفيذ والدفع وسيقوم CI بإعادة نشر المكدس باستخدام التكوين الجديد. هذا غير ممكن بدون بعض القرصنة لتغيير اسم الملف أو بعض الآليات الأخرى. بالتأكيد يمكننا فحص الملف ، كحد أدنى ، أو البحث عن تغييرات المحتوى والتحديث بناءً على الملف نفسه؟ بشكل عام ، يبدو أننا سنعود إلى الوراء. ارمي الدعم لـ K8s الآن وهذا يجعلني أتساءل عما إذا كان السرب سوف يذبل على الكرمة حتى يفقد الاستخدام الكافي الذي يسقط بهدوء.
أيضًا ، FWIW ، التكوينات هي حقًا subpar في تجربتي للتكوينات الفعلية. كنت أتخيل (آمل) أنه يمكنني الحصول على /application/config.conf في المصدر. قم بتحديث هذا الملف والتنفيذ والدفع وسيقوم CI بإعادة نشر المكدس باستخدام التكوين الجديد. هذا غير ممكن بدون بعض القرصنة لتغيير اسم الملف أو بعض الآليات الأخرى.
ntwrkguru الحل البسيط هو تغيير ليس اسم الملف ، ولكن اسم التكوين نفسه. لقد استخدمت مخطط إصدار لأسماء التكوين الخاصة بي ، على سبيل المثال ، config_v1
، config_v2
، ..
لذلك تذكر فقط تحديث هذا الإصدار بعد تغيير ملف التكوين.
services:
app:
[...]
configs:
- source: config_v2
- target: /config.yml
configs:
config_v2:
file: ./config.yml
أفهم السبب وراء عدم وجود تكوينات وأسرار ذات إصدار حتى الآن ، لذلك أنا شخصياً على ما يرام حاليًا مع هذا الحل (السهل).
شكرًا djmaze ، ولكن هذا أمر مثير للسخرية في النهاية يجب القيام به عندما يكون هناك تتبع إصدار متأصل مدمج في كل نظام تحكم بالمصادر. أيضا ، شكرا على الرابط. لقد علقت هناك أيضا. لا أفهم سبب اهتمام Docker بالإصدار بخلاف الإصدار الحالي. السبب الوحيد الذي يمكنني رؤيته لضرورة إصدار هذه الإصدارات هو الرجوع إلى الحالة السابقة ، ولكن هناك الكثير من الأشياء التي يجب تتبعها هناك أيضًا على أي حال ، فما هو أكثر من ذلك؟ (يقول الرجل الذي ليس عليه كتابة الكود) :-)
جرب هذا:
echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name
يستخدم docker-compose لتحليل ملف التكوين ، واستبدال المتغيرات البيئية ، وشرائط التحذيرات من الإخراج ، ثم توجيهها إلى حزمة الرصيف التي يتم نشرها عبر stdin.
استبدل "-f stack.yml" باسم ملف التكوين الخاص بك أو احذفه لاستخدام docker-compose.yml الافتراضي.
+1
بعد عام وما زال يتعين علينا اختراق هذا للعمل. اعتبارًا من 17.09.1 ، لن يتم استبدال docker stack deploy -f compose.yml
باستخدام متغيرات shell المعروفة.
$ 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
أي متغيرات للعلامات ستنتج invalid reference format
.
بعد عام وما زال يتعين علينا اختراق هذا للعمل. اعتبارًا من 17.09.1 ، لن يتم استبدال مكدس عامل الإرساء -f compose.yml باستخدام متغيرات shell المعروفة.
راجع كيفية الاحتفاظ بمتغيرات البيئة عند استخدام 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
شكرا ، ولكن هل من كلمة عن مجرد دعم استبدال متغير من ملف؟
[تحرير] لا ينبغي أن تكون هذه مشكلة (ولكن يمكن أن تكون كذلك) لأنني أستخدم Ansible لأداء المهمة باستخدام become: yes
، لكن المستخدم لا يزال هو نفسه المستخدم الذي يقوم بمصادر متغيرات البيئة.
لا أصدق أن هذا غير ممكن. نود الاحتفاظ بملف مكدس واحد وأن نكون قادرين على تغيير خيارات النشر باستخدام المتغيرات الديناميكية.
هذا من شأنه أن ينجح ولكنه قبيح وهاكر:
echo "$(docker-compose -f stack.yml config 2>/dev/null)" | docker stack deploy -c- stack_name
لقد كنت العبث بهذا لعدة ساعات ويبدو أنني أقوم ببعض أعمال البرنامج النصي في الخلفية (سأستخدم CI للقيام بذلك) لإنشاء ملف DAB من هذه الأجزاء المختلفة. سيكون من الجيد أن يكون لديك أداة عامل ميناء تقوم بهذا ... :-) ربما تضيف --env-file version.env
مضافًا إلى docker-compose bundle
؟
في حالة الاستخدام الخاصة بي ، أريد استخدام "بيان" version.env
لتتبع إصدارات الحاويات / الصور التي تشكل النظام الأساسي والتحكم فيها. تبدو عمليتي كما يلي:
.env
.env
لتعبئة متغيرات الصَدَفةdocker-compose -f stack.yml config > docker-compose.yml
docker-compose pull
لتسجيل ملخصات الصورةdocker-compose bundle -o stack.version.dab
في هذه المرحلة ، من الناحية المثالية سأتمكن من الحصول على docker deploy --host manager.swarm.com --bundle-file stack.version.dab --with-registry-auth --resolve-image always stack-name
، لكنني أدركت أن ذلك غير ممكن الآن. في هذه الحالة ، أود نقل ملف DAB إلى المدير وتنفيذ docker deploy
.
هل هذا هو سير العمل الذي كان يدور في ذهن عامل ميناءhaJeztah؟ هل هناك طريقة أفضل؟
[تحرير] هذا لا يعمل لأن DAB يتجاهل توجيهات volume:
و network:
و deploy:
. لقد اعتدت ببساطة تحديد مصدر ملف env إلى shell ، وإعادة إنشاء ملف إنشاء مؤقت ، ثم نشر ذلك.
أتمنى لو تمت قراءة ملفات .env
افتراضيًا كما هو الحال في Docker Compose و --env-file
(باختصار -e
) ستتم إضافتها لـ docker stack deploy
لتتمكن من التجاوز متغيرات البيئة والافتراضيات من ملف .env
.
+1
سيكون من الملائم جدًا قراءة .env في المقام الأول كما يفعل عامل الإرساء.
إما بشكل افتراضي أو مجرد تمرير ملف env كمعامل في سطر أوامر docker stack.
يبدو أن الحلين المذكورين بالفعل (_ ابحث عنهما أيضًا أدناه_) يعملان على الرغم من أنهما قبيحان قليلاً مقارنةً بـ "الإصلاح" المقترح.
_echo "$ (docker-compose -f stack.yml config 2> / dev / null)" | نشر كومة عامل ميناء -c- stack_name_
_env $ (cat .env | grep ^ [AZ] | xargs) نشر مكدس عامل ميناء - comppose-file docker-compose.yml [STACK_NAME] _
أود أن أضيف أن تثبيت عامل الإرساء فقط لتتمكن من معالجة هذه المتغيرات يمكن أن يكون خطيرًا جدًا في الواقع.
إذا قام أي شخص بنشر المكدس باستخدام docker-compose up -d عن طريق الخطأ بدلاً من استخدام نشر مكدس عامل الإرساء ، فمن المحتمل أن يؤدي ذلك إلى حدوث أخطاء في التطبيقات وتلف الملف.
يعد وجود الاستيفاء المتغير للبيئة في النشر هو الحل الأفضل للتكامل المستمر.
تتمثل إحدى المشكلات المتعلقة باستخدام ".env" في أنه يتداخل مع أسماء ملفات مماثلة تستخدمها ، على سبيل المثال ، Ruby on Rails ، حيث تكون القدرة على تحديد ملف بيئة حسب الوسيطة أفضل.
اقتراحات ntelisil جيدة ويمكن استكمالها أو تعديلها من خلال:
يمكنك استخدام envsubst (جزء من gnu gettext):
envsubst <ملف
إستعملت:
$ envsubst < docker-compose.yml-template > docker-compose.yml
وقد نجح ذلك بشكل جيد ، لكنني كنت بحاجة إلى إضافة 3 ميغا بايت أو نحو ذلك إلى الحاوية الخاصة بي.
لطيف rnickle ، ولكن لا يزال "متطرفًا" مقارنة بقدرة Docker على القيام بذلك بالطريقة التي اعتاد عليها. يبدو (ويرجى رجال Docker تصحيح لي إذا كنت مخطئًا) أن هناك القليل جدًا من الجهد المبذول في وضع السرب منذ الإعلان عن دعم K8s ، لذلك أشك في أنه سيتم معالجة أي من هذه الانحدارات.
وقد نجح ذلك بشكل جيد ، لكنني كنت بحاجة إلى إضافة 3 ميغا بايت أو نحو ذلك إلى الحاوية الخاصة بي.
إذا تم تعيين متغيرات البيئة ، فيجب أن يقوم docker slack deploy
بتحويلها بالفعل
مقارنة بقدرة Docker على القيام بذلك بالطريقة التي اعتاد عليها.
لم يكن لدى Docker هذه الميزة مطلقًا ؛ كان عامل البناء يؤلف ؛ يقوم docker compose and docker stack بنشر مشاركة تنسيق الملف ولكن ليس جميع سلوكيات البرنامج نفسه.
أن هناك القليل من الجهد المبذول في وضع السرب منذ الإعلان عن دعم K8s
تتم معالجة ملف الإنشاء بالكامل من جانب العميل ، ويتم استخدامه لكل من k8s و swarmkit ، لذلك لا شيء يتباطأ في هذا المجال ، بخلاف "هناك الكثير الذي يمكننا القيام به في أي وقت"
لأولئك الذين ينتظرون هذه الميزة ؛ سيحتوي الإصدار القادم على دعم لملفات الإنشاء المتعددة مقابل docker stack deploy
، لذلك إذا كنت تستخدم هذه الميزة حاليًا في إنشاء عامل الإرساء: فإن إصدار عامل الإرساء القادم سيدعم هذا أيضًا
بغض النظر عن الدلالات ، شكرا على التحديث. عندما أقول Docker ، فأنا لا أعني بالضرورة البرنامج الخفي أو المحرك ، ولكن الشركة التي تبني الأدوات. نشأة التعليق حول وجود القليل من الجهد ينبع حقًا من حقيقة أن وضع السرب قد توقف منذ أكثر من عام ولا يزال متأخراً عن المكان الذي كنا فيه مع عقدة واحدة باستخدام التركيب.
يمكنني أن أقدر أنهما مختلفان ، لكنهما يستخدمان نفس تنسيق الملف ، لكن هذا يؤدي في الواقع إلى مزيد من الارتباك ، وربما يخيب الأمل ، عندما يكتشف المستخدمون أنه يتعين عليهم استبدال الميزات باستخدام السرب. هذا وحقيقة أن ملفات DAB لا تزال مدرجة على أنها تجريبية. لسوء الحظ ، اتخذنا قرارًا باستخدام وضع السرب في مشروع كبير ، وإلا فلن أهتم بذلك. لحسن الحظ ، لن نرتكب هذا الخطأ مرة أخرى.
[تعديل]
إذا تم تعيين متغيرات البيئة ، فيجب أن تقوم عملية نشر فاصل عامل الإرساء بإقحامها بالفعل
القيام بذلك في بيئة CI هو ألم الحمار الملكي. بشكل أساسي ، انتهى بي الأمر بتثبيت الإنشاء ، وتحديد مصادر البيئة ، وغسل ملف الإنشاء (بعد سحب الصور) ثم بصق ملف إنشاء جديد للاستخدام مع stack deploy
. (ولن أبدأ حتى في الحديث عن مدى الألم عندما لا يعني $ # $ :latest
:latest
في وضع السرب ، نظرًا لأن هذه المشكلة تتعلق بالتحديد بالاستيفاء المتغير.)
_EDIT: آمل ألا يظهر هذا المنشور بقوة. أنا أحب مفهوم Docker Stack وأعتقد أن مجموعة Docker بأكملها مدعومة جيدًا. يبدو أن Docker (المؤسسة) لا تعرض حاليًا منتجاتها بالطريقة نفسها التي يعرضها المستخدمون ، وهذا أمر مؤسف ويبدو أنه سبب معظم المشكلات التي واجهتها باستخدام Compose and Stack.
لم يكن لدى Docker هذه الميزة مطلقًا ؛ كان عامل البناء يؤلف ؛ docker compose and docker stack تشارك في تنسيق الملف ولكن ليس بالضرورة جميع سلوكيات البرنامج نفسه.
أشعر أن هذا البيان يكشف عن انفصال أساسي بين طريقة عرض مطوري Docker والمستخدمين لهذه المنتجات. بصفتي مستخدمًا ، سواء كنت أعمل مع Docker Engine أو Docker Compose أو Docker Swarm ، فهذه كلها Docker ويجب أن تتصرف باستمرار قدر الإمكان.
ما أفهمه من الغرض من هذه المنتجات هو:
تتمثل إحدى نقاط البيع الرئيسية لـ Docker (والحاويات بشكل عام) في سهولة إعادة استخدام نفس التطبيق في بيئات متعددة. لذلك ، يجب أن يكون التركيب مضافًا إلى Engine ويجب أن يكون Stack مضافًا إلى Compose. نظرًا لأنهم يشاركون تنسيق الملف نفسه ، فإن عدم دعم Stack لميزات Compose يؤدي إلى إرباك المطورين وزيادة التعقيد في عمليات CI.
لن أقول إن التركيب مخصص لـ dev و stack for prod ، بالضرورة. أرى أن إنشاء عبارة عن تطبيق متعدد الحاويات أو "نظام" ومكدس لعمليات النشر متعددة المضيف باستخدام وضع السرب باعتباره المجدول / المنسق. خلاف ذلك ، فإن تعليقك على الفور 100٪. أشعر أيضًا بالإحباط (إذا لم تكن تعليقاتي الأخرى واضحة) من وجود انفصال بين المطورين والمستخدمين فيما يتعلق بكيفية استخدام المنتج (المنتجات).
أوه ، واو. انضممت إلى الارتباك والألم أثناء تقييم سرب عمال النقل لمشروع كبير أيضًا.
الأسرار كلها ممتعة وألعاب ، لكن ليست كل صور عامل الميناء الخارجي تدعم قراءة الأسرار من الملفات. لا أريد التعديل لكل منهم ووضع صورة مخصصة. قد أستخدمها في مشاريعي ، نعم ، لكن بالنسبة للمشاريع الخارجية لن يكون الأمر كذلك.
هذا يترك المتغيرات env. لكن مهلا ، يتصرفون بشكل مختلف من تكوين إلى مكدس! تخيل دهشتي عندما لاحظت أنها لا تعمل حقًا.
كيف يمكن أن يكون لديك مكدس عامل بدون دعم env؟ سيكون الأفضل في رأيي --env-file = dev.env ، لذلك لن يتداخل مع ملفات env أخرى ... لكن دعم هذا أمر مروع. يجب أن أعود إلى k8s لسوء الحظ ، حيث أن المكدس الذي فقد هذا منذ البداية ، يمكن أن يكون خيارًا مروعًا أثناء الإنتاج ، من يعرف عدد الأشياء الأخرى التي ستفقد.
لقد مر عامان وما زلنا هكذا ... لا أريد أن أكون وقحًا ، لكن هيا! إنها مسألة إعادة استخدام القليل من التعليمات البرمجية من عامل البناء!
هناك مشكلة أخرى مماثلة واجهتني وهي أنه حتى إذا كنت تستخدم env_file ، فإن السلوك لا يزال غير متماثل تمامًا.
أستخدم env_file لتحميل المسارات المحددة من جذر المشروع ، لكن ملف التركيب الخاص بي موجود في دليل فرعي مختلف. لبدء التشغيل باستخدام docker-compose ، أستخدم فقط --project-directory. -f path / to / docker-compose.yml
docker stack
لا يسمح لي بتحديد دليل المشروع ، مما يتسبب في فشل تحميل جميع ملفات env_files الخاصة بي.
لا يعمل تغيير env_file إلى "../../path/to/envrc" مع docker-compose ، حيث يجب أن تكون هذه الملفات داخل مسار جذر المشروع
+1
+1
إجراء 1+ سيكون مفيدًا حقًا. لا ترى جانبًا سلبيًا حقًا.
إنه لأمر غبي بشكل لا يصدق أن عامل التحميل لا يدعم هذا حتى الآن.
+1 @ joao-fidalgo إنه بالتأكيد كذلك.
+1
لقد اصطدمت للتو بنفس الشيء الذي نجربه سربًا. لقد قرأت من خلال جميع الرسائل في سلاسل الرسائل المختلفة وتركت محبطًا للغاية. IMO ، تم تقديم بعض النقاط الجيدة والحجج القوية بواسطة ntwrkguru وآخرون. آمل أن نتمكن من النظر فيها للحصول على هذه الميزة ؛ لن تقطعها الخارقة.
ملف env
export MYSQL_USER=user
source .env && docker stack deploy
ستعمل أيضًا مع docker-compose up
للباش
ملف env
export MYSQL_USER=user
source .env && docker stack deploy
ستعمل أيضًا مع
docker-compose up
هذا من شأنه أن يعمل فقط مع bash وليس الأصداف الأخرى.
هذا حيرني كالمجنون. سيظهر تطبيقي باستخدام تكوين عامل الإرساء ، ولكن ليس مع نشر مكدس عامل الإرساء. يجب أن يكون هناك على الأقل إخلاء مسؤولية معروض بشكل بارز في المستندات
لكن IMO هذا خطأ ، ويؤدي إلى تدهور تجربة عامل الميناء.
نحن بحاجة إلى إجابة عن هذا
ما يقرب من عامين ولم يلتقطها أحد ... لا تحبس أنفاسك jorgelimafeitosa
لا أعتقد أن CLI ستقوم أبدًا بإضافة دعم .env
. تم إنشاء الأمر docker stack deploy
في الأصل مع وضع ملفات حزم التطبيقات الموزعة في الاعتبار (ومن هنا جاء الخيار --bundle-file
). تم إنشاء ملفات DAB بواسطة Docker Compose باستخدام الأمر docker-compose bundle
. سيتم التعامل مع .env
وميزات الإنشاء الأخرى بواسطة docker-compose
، قبل أن يتم تمريرها إلى docker stack deploy
. كان الدعم المباشر لإنشاء الملفات في docker stack deploy
دائمًا أكثر من حل وسط.
الوعد الأصلي لملفات DAB موجود الآن في تطبيق Docker ، والذي لا يعالج أيضًا .env
.
لدي مطوري استخدام docker-compose config
لمعالجة مشاريع Docker Compose مسبقًا قبل تمريرها إلى docker stack deploy
. يمكنك القيام بذلك في سطر واحد باستخدام:
docker stack deploy -c <(docker-compose config) stack-name-here
بهذه الطريقة ، يتم تطبيق جميع ميزات Docker Compose بما في ذلك معالجة .env
بالكامل.
kinghuang حاولت الحل الخاص بك ، لكنه لم ينجح. ينتج عن "docker-compose config" الإخراج الصحيح في نفس الدليل ، لكن "docker stack publish -c docker-compose.yaml my_stack" لن يحل محل المتغيرات من .env. ماذا ينقصني؟ هذا إصدار Docker 18.09.0 ، بناء 4d60db4.
kinghuang حاولت الحل الخاص بك ، لكنه لم ينجح. ينتج عن "docker-compose config" الإخراج الصحيح في نفس الدليل ، لكن "docker stack publish -c docker-compose.yaml my_stack" لن يحل محل المتغيرات من .env. ماذا ينقصني؟ هذا إصدار Docker 18.09.0 ، بناء 4d60db4.
نشر حزمة عامل ميناء -c <(عامل ميناء-تكوين -f عامل إرساء-تكوين-frpc-swarm-traefik.yml config)
تضمين التغريدة
open / dev / fd / 63: لا يوجد مثل هذا الملف أو الدليل
تحذير: تستخدم بعض الخدمات (مشروع 1 ، مشروع 2) مفتاح "النشر" ، والذي سيتم تجاهله. لا يدعم الإنشاء تكوين "النشر" - استخدم docker stack deploy
للنشر في سرب.
تضمين التغريدة
فقط بيئة الجذر لن تبلغ عن خطأ.
لا يكون دعم .env
و env_file
منطقيًا دائمًا في بيئة النشر / الإنتاج. لا تحتاج إلى وصول مباشر إلى نظام الملفات لأي من الميزات الأخرى لـ Docker Swarm. لذلك ، المصمم / المشغل المسؤول لهذا النظام لا يريد أن يمنحك القدرة على تفريغ ملفات البيئة في نظام الملفات.
من الناحية النظرية ، يمكن أن يدعم Swarm تحميل الأسرار في البيئة تلقائيًا ولكن راجع https://github.com/moby/moby/issues/30866#issuecomment -278924983 لمعرفة السبب الذي يجعل ذلك ليس فكرة جيدة من الناحية الأمنية.
ما يمكنك فعله اليوم هو استخدام الأسرار وتحميلها في بيئة تطبيقك عند تشغيل الحاوية. يمنحك ذلك التحكم في مكان رؤية قيم البيئة السرية.
+1
يجب أن يدعم نشر مكدس عامل ميناء - env-file.
أنا نفسي أعاني من إعادة استخدام نفس ملف .yml لنشر حزم مختلفة لبيئات التطوير / الاختبار / الإنتاج ولا أريد التعامل مع بعض مصادر متغيرات البيئة قبل نشر المكدس. هذا عرضة للخطأ للغاية (وألم في ** أيضًا لتذكر الأوامر الدقيقة في كل مرة).
في حالتي الخاصة ، أريد على سبيل المثال تعيين أسماء فهرس مختلفة (elasticsearch) لكل بيئة - لكن باقي التكوين يظل كما هو. هذا لا علاقة له "بالأسرار" كما ذكر في المنشورات السابقة.
يبدو أن هناك حاجة حقيقية لنشر ملف --env لمكدس عامل السفن استنادًا إلى محفوظات التعليقات أعلاه ولكن للأسف لا يبدو أن مطوري Docker يرون ذلك.
في بيئة السرب الخاصة بي ، استقرت على بعض الحلول:
ما عليك سوى تحديد ملف .env في docker-compose.yml الخاص بك ويعمل:
env_file:
- .env
عمل حول في بوويرشيل لاستخدامه على النوافذ لتحليل ملف .env قبل استدعاء عامل الإرساء:
switch -regex -file "./.env" {"^ \ s ([^ #]. +؟) \ s = \ s (. )" {$ name، $ value = $ تطابق [1..2]؛ مجموعة العنصر "env: $ name" $ value}}
مستوحى بشكل كبير من تحليل ملفات .ini: https://stackoverflow.com/questions/417798/ini-file-parsing-in-powershell
الحل الآخر هو: set -a && . .env && set +a && docker stack deploy...
.
هذا سخيف. لقد قضيت اليوم كله في محاولة للحصول على هذا العمل. هناك حاجة على الأقل إلى إخلاء المسؤولية في مكان ما في المستندات بحيث لا تتم قراءة .env بواسطة أوامر docker stack
.
تضمين التغريدة الوثائق تقول:
هام: لا تعمل ميزة ملف .env إلا عند استخدام أمر Docker-Compose ولا تعمل مع نشر مكدس عامل الإرساء
من الاهتمام. ما الذي يفعله الأشخاص حاليًا عندما يكونون في وضع السرب ، ويريدون تحديث صورة عامل الإرساء المبنية حديثًا من ، على سبيل المثال تطبيق ap plication: v1 to ap plication: v2 ، نفس الخدمة (لم يتغير شيء آخر)؟
هذا هو سبب مجيئي إلى هذه القضية. لهذا أنا مهتم.
حاليًا في docker-compose ، من التافه الحصول على أتمتة للتفاعل مع ملف غير مُتتبع للتحكم في المصدر . env
لتحديث نسخة الصورة ، ثم docker-compose up -d
غالبًا ما أستخدم sha كإصدار صورة عامل إرساء لعمليات النشر "التدريج" (علامات git المستخدمة للإصدارات الفعلية بعد دورات اختبار كافية) ، لذلك ليس من الممكن حقًا إلزام إصدار الصورة الجديد بالتحكم في المصدر.
هل من الممكن تحديث سر عامل الإرساء (على الرغم من أنه ليس سرًا حقًا) كحل بديل؟ هل هذا ما يفعله الناس ، أم أن هناك شيئًا آخر يتم فعله.
أطلب من الزوار المستقبليين لهذه المشكلة ، حتى يأتوا بالفعل بأفضل الممارسات الحالية ، لأن الوظيفة التي كانوا يبحثون عنها غير موجودة (حتى الآن؟).
مرحبًا ، أنا مشغول بالبحث في نشر المكدس للاستخدام في خطوط أنابيب CI / CD ، وستكون القدرة على استخدام ملف .env مفيدًا جدًا ، أي ملاحظات حول ما إذا كان سيتم تقديم هذا الخيار في أي مرحلة؟
يبدو أن التوصية الرسمية هي ، في الواقع ، لترحيل رمز الصورة الخاص بك لدعم قراءة هذه الأنواع من المتغيرات من ملف نصي أسرار - الاحتفاظ بالقدرة على قراءة هذه أيضًا من المتغيرات البيئية للتوافق مع الإصدارات السابقة غير المكدسة / السرب.
يستخدم المثال سرًا واحدًا لكل ملف نصي ، مما يتجنب الاضطرار إلى تحليل ملف env القديم.
تمت إعادة صياغته من الوثائق الموجودة على 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
تنهد
يجب أن يكون هذا أكثر وضوحا في الوثائق. على الرغم من أنه تم الاستدلال على أن .env غير مدعوم في قسم استبدال المتغير لكل lengxuehx ، لم يذكر أنه تم تجاهل env_file لعمليات نشر المكدس.
يمكنني أن أؤكد أن الحل الذي اقترحه kinghuang يعمل ولا يستبعد مفتاح النشر كما قال أحدهم.
docker stack deploy -c <(docker-compose config) stack-name-here
يجب أن يكون هذا أكثر وضوحا في الوثائق. على الرغم من أنه تم الاستدلال على أن .env غير مدعوم في قسم استبدال المتغير لكل lengxuehx ، لم يذكر أنه تم تجاهل env_file لعمليات نشر المكدس.
أستطيع أن أؤكد أن env_file تستخدم وتعمل من أجل نشر أمر المكدس ، تماما كما يفعل عامل الإرساء.
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
لتلخيص ، لأشخاص مثلي ، الذين قرأوا هذا حتى الآن:
docker stack deploy
"الاستبدال المتغير" ولكنك تحتاج إلى تعيين متغيرات البيئة من الملف .env
بطريقة ما. تم شرح العديد من الخيارات أعلاه. أحد أفضل الحلول هو استخدام docker-compose config
كمعالج مسبق.docker stack deploy -c <(docker-compose config) STACK_NAME
.env_file
في الملف docker-compose.yml
على تعيين متغيرات البيئة في الحاوية التي تم إنشاؤها وليس في الملف docker-compose.yml
نفسه (وبالتالي لا يمكن استخدامه كبديل لـ " استبدال متغير ").تم تصحيحي بواسطةthaJeztah.
لا يدعم Docker الاستبدال المتغير باستخدام نشر مكدس عامل الإرساء ، ولا يعمل أي من الحلول غير المقترحة.
لا يدعم docker stack deploy
الاستبدال المتغير ، لكنه لا يقيم ملف .env
؛ في المثال أدناه ، تم تعيين HELLO_VERSION
على linux
، وستستخدم الخدمة علامة hello-world:linux
(بدلاً من العلامة الافتراضية 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
ومع ذلك ، لا يزال بإمكانك استخدام متغيرات البيئة باستخدام المعامل env_file في ملف docker-compose.yml الخاص بك
يخدم env_file
غرضًا مختلفًا (وهو ما يعادل docker run --env-file
) ؛ يحدد الخيار env_file
ما هو env-vars لتعيينه على الحاوية التي تم إنشاؤها ، ولكن لا يتم استخدامه في ملف الإنشاء نفسه (ولا يتم استخدامه لاستبدال المتغيرات في ملف الإنشاء قبل نشر المكدس).
عانيت من نفس المشكلة مع اختلافات طفيفة أخرى بين تكوين عامل الإرساء ومكدس عامل الإرساء.
انتهى بي الأمر بإنشاء https://github.com/egyel/dcsh برنامج نصي / أداة للتعامل مع هذه المشكلة مع الأنابيب.
مرحبًا بالجميع ، لقد ساعدني هذا في وضع env_file في تكوين عامل الإرساء الخاص بي:
env_file: /path/to/env/file
ليس
env_file:
- /path/to/env/file
لقد رأيت هذا للتو من منشور آخر ويمكنني فقط التكهن لماذا يعمل (مثل تكهناتك) ولكننا نحتاج إلى تأكيد لماذا يعمل هذا كعامل عامل مذكور صراحة في docu أن env_file لا يعمل.
ما أفهمه هو أنه لا يمكن استخدام ملفات env لملء العناصر النائبة
ملف docker-stack.yml ولكن لا يزال من الممكن توفيرها للحاويات.
لاحظ أن ما تفعله لا يسمح لك بتعيين اسم الصورة من
ملف env على سبيل المثال.
في يوم الأحد 17 مايو 2020 الساعة 06:08 كتب raphyphy [email protected] :
[صورة: صورة]
https://user-images.githubusercontent.com/30310576/82135555-a1e4be00-9836-11ea-9df4-a1b82e014b0e.png
مرحبًا بالجميع ، لقد ساعدني هذا في وضع env_file في تكوين عامل الإرساء الخاص بي:env_file: / path / to / env / file
ليسenv_file:
- / مسار / إلى / إنف / ملف
لقد رأيت هذا للتو من منشور آخر ولا يمكنني إلا التكهن لماذا يعمل
(مثل تخمينك) لكننا نحتاج إلى تأكيد لسبب ذلك
العمل كعامل رصيف مذكور صراحة في docu أن env_file لا
الشغل.-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/29133#issuecomment-629740002 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ABHLQMCARDQGJQIBWCQKAYLRR5PMHANCNFSM4CYRHCTA
.
حل عامل البناء المذكور أعلاه:
docker stack deploy -c <(docker-compose config) stack-name-here
له عيب (بالنسبة لي) أن أشياء مثل ملفات .env
وخاصة ملفات docker-compose.override.yml
هي عادة جزء أكثر من بيئة التطوير الخاصة بي. لا أريد حقًا جلب هؤلاء عند النشر في الإنتاج.
انتهى بي الأمر بالحصول على docker-compose-production.yml
منفصل حيث كنت أتحكم في الأشياء بعناية ، على الرغم من أن ذلك ينطوي على بعض الازدواجية.
لا أعتقد أن CLI ستقوم أبدًا بإضافة دعم
.env
. تم إنشاء الأمرdocker stack deploy
في الأصل مع وضع ملفات حزم التطبيقات الموزعة في الاعتبار (ومن هنا جاء الخيار--bundle-file
). تم إنشاء ملفات DAB بواسطة Docker Compose باستخدام الأمرdocker-compose bundle
. سيتم التعامل مع.env
وميزات الإنشاء الأخرى بواسطةdocker-compose
، قبل أن يتم تمريرها إلىdocker stack deploy
. كان الدعم المباشر لإنشاء الملفات فيdocker stack deploy
دائمًا أكثر من حل وسط.الوعد الأصلي لملفات DAB موجود الآن في تطبيق Docker ، والذي لا يعالج أيضًا
.env
.لدي مطوري استخدام
docker-compose config
لمعالجة مشاريع Docker Compose مسبقًا قبل تمريرها إلىdocker stack deploy
. يمكنك القيام بذلك في سطر واحد باستخدام:docker stack deploy -c <(docker-compose config) stack-name-here
بهذه الطريقة ، يتم تطبيق جميع ميزات Docker Compose بما في ذلك معالجة
.env
بالكامل.
يعمل هذا مثل السحر ، ضع في اعتبارك إذا كان ملف الإنشاء الخاص بك لا يحتوي على اسم "docker-compose.yml" يجب أن يتضمن الأمر اسم ملف الإنشاء الفعلي.
نشر حزمة docker -c <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config) CUSTOM-STACK
حذار من هاك <(docker-compose -f CUSTOM-COMPOSE-FILENAME.yml config
!!! ناتج docker-compose config
و docker-compose -f myfile.yml config
ليس بالضرورة هو نفسه! يقوم الأخير أحيانًا بلف متغيرات env في علامات اقتباس إضافية ، لذلك سيكون الناتج خاطئًا!
مثال:
environment:
SERVER_URL: '"xxx"'
بدلا من
environment:
SERVER_URL: xxx
هل تم تتبع هذه المشكلة في مكان ما بالفعل؟
التعليق الأكثر فائدة
whoan أنا أستخدم هذا كحل بديل:
بهذه الطريقة ، لا تتعطل المتغيرات في نافذة المحطة