Moby: لا يقوم "Docker stack publish" في 1.13 بتحميل ملف "env" كما يفعل "docker-compose up"

تم إنشاؤها على ٥ ديسمبر ٢٠١٦  ·  93تعليقات  ·  مصدر: moby/moby

لاختبار وظيفة 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
arestack areswarm kinenhancement

التعليق الأكثر فائدة

whoan أنا أستخدم هذا كحل بديل:

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

بهذه الطريقة ، لا تتعطل المتغيرات في نافذة المحطة

ال 93 كومينتر

هذا حسب التصميم. يعد الدعم .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 لتسجيل ملخصات الصورة
  • قم بتشغيل ملف DAB 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 جيدة ويمكن استكمالها أو تعديلها من خلال:

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

يمكنك استخدام 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 مخصص لبناء وتشغيل الحاويات الفردية
  • Docker Compose مخصص لتشغيل مجموعة من الحاويات قيد التطوير
  • Docker Stack مخصص لنشر الحاويات في الإنتاج

تتمثل إحدى نقاط البيع الرئيسية لـ 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 يرون ذلك.

في بيئة السرب الخاصة بي ، استقرت على بعض الحلول:

  • الأسرار / التكوينات ، التي أستخدمها لتحميل ملفات التكوين والشهادات.
  • بعد مشاهدة عرض توضيحي لبيئة تطوير Azure حيث كان لديهم برنامج استيفاء متغير يقومون بتشغيله قبل إرسال ملف إنشاء ، كتبت ملفي الخاص الذي أضعه في تدفق إصدار GitLab الخاص بي.

ما عليك سوى تحديد ملف .env في docker-compose.yml الخاص بك ويعمل:

env_file:
  - .env

انظر https://stackoverflow.com/questions/44694640/docker-swarm-with-image-versions-externalized-to-env-file

عمل حول في بوويرشيل لاستخدامه على النوافذ لتحليل ملف .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 .
  • على الرغم من أن Docker قدم إمكانات التهيئة والأسرار ، إلا أن لديهم حالات الاستخدام الخاصة بهم ولكنهم لن يفعلوا نفس الشيء مثل "الاستبدال المتغير".
  • ستعمل المعلمة 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 برنامج نصي / أداة للتعامل مع هذه المشكلة مع الأنابيب.

image
مرحبًا بالجميع ، لقد ساعدني هذا في وضع 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

هل تم تتبع هذه المشكلة في مكان ما بالفعل؟

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات