Werkzeug: 0.15.0 يسبب خطأ OSError: [Errno 8] خطأ تنسيق Exec: في Docker لـ Windows

مرحبا نفس المشكلة هنا. اختبارها على

• Centos 7.4 مع بيثون 3.6
• Mac OSX 10.14.3 مع بيثون 3.7

يحدث هذا بسبب التغييرات في _get_args_for_reloading() في _reloading.py.

بالنظر إلى الكود أعلاه في ملف يسمى app.py ، حيث يكون cwd () هو /home/user/Projects/test/

ينتج عن _get_args_for_reloading() ما يلي:

بـ 0.14.1 :

['/home/user/.virtualenvs/test-ChRUEUMK/bin/python', 'app.py']

بـ 0.15.0

['/home/user/Projects/test/app.py']

يؤدي إلحاق /home/user/.virtualenvs/test-ChRUEUMK/bin/python بالمسار إلى حل المشكلة.

shinuza تحقق مما إذا كان app.py قابلاً للتنفيذ ، إذا كانت الإجابة بنعم - اضبط chmod 644 app.py. أو الطريقة الثانية ، أضف shebang في الجزء العلوي من app.py like #! / usr / bin / env python

shinuza هناك https://github.com/pallets/werkzeug/blob/0.15.x/src/werkzeug/_reloader.py#L90 خطوط 90-94 the "" /home/user/.virtualenvs/test-ChRUEUMK/bin / python '"تمت إزالته إذا كان app.py قابلاً للتنفيذ.
و OSError: [Errno 8] خطأ في تنسيق Exec: '/usr/src/app/app.py حدث لأن app.py لا يحتوي على سطر shebang (https://stackoverflow.com/questions/27606653/oserror-errno- 8-exec-format-error)

kamyanskiy لقد اكتشفت هذا للتو عند قراءة الكود ولكن الخطأ يجب أن يكون غامضًا كما هو الآن.

أيضًا ، إذا قمت بتشغيل python app.py بشكل صريح ، فلا يجب أن تقوم العملية الفرعية بأي افتراض وتغيير طريقة تشغيل التطبيق. على سبيل المثال: العمل مع آلة افتراضية مع مجلد مشترك يجعل كل الملفات قابلة للتنفيذ بشكل افتراضي.

shinuza لا أعتقد أنه خطأ فادح ، بمعنى آخر ، إنه أكثر صرامة الآن من ذي قبل. لذلك لا ينبغي أن يكون لدي app.py قابل للتنفيذ بدون shebang ، فهذا غير منطقي. وثانيًا ، لا يجب تشغيل ملف تنفيذي باستخدام shebang مثل "python app.py". لكنني أوافق ، ربما كان ذلك غير متوقع بالنسبة لك بالنسبة لي :) للتغلب على هذه المشكلة ، ما عليك سوى إضافة shebang إلى تطبيقك. آمل أن يساعدك هذا.

إذا قمت بتمييز أحد البرامج النصية على أنه قابل للتنفيذ ، فيجب عليك إضافة تعليق مترجم فوري إلى الأعلى. يمكنك استخدام أداة مثل خطاف check-executables-have-shebangs للالتزام المسبق لفرض ذلك.

إذا كنت لا تنوي أن يكون البرنامج النصي قابلاً للتنفيذ مباشرة ، وتريد أن تطلب python script.py بدلاً من ذلك ، فلا يجب عليك وضع علامة عليه قابل للتنفيذ.

كما قلت ، أتفق مع المنطق الرئيسي هنا. أنا لا أتفق مع طريقة التعامل مع الخطأ وكذلك حقيقة أن رسالة الخطأ غير مفهومة إلا إذا كنت تعرف التفاصيل الفنية أو تقرأ الكود. يجب أن يتم توثيقه على الأقل في سجل التغيير.

ليس لدينا سيطرة على رسالة الخطأ التي تأتي من Linux. يتم سرد حقيقة أننا قمنا بتغيير كيفية معالجة الملفات القابلة للتنفيذ في سجل التغيير:

لن تقوم أداة إعادة التحميل بإلحاق ملف Python التنفيذي بسطر الأوامر إذا تم وضع علامة على ملف Python بأنه قابل للتنفيذ. هذا يسمح لأداة إعادة التحميل بالعمل على NixOS. # 1242

جعل الملف غير قابل للتنفيذ يعمل. خط شيبانج ليس كذلك بالنسبة لي. أحصل على ملف لم يتم العثور على أخطاء ، بدلاً من ذلك. كان هذا أول شيء حاولت.

مع #!/usr/bin/env python3 :

λ docker run flask_test
 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: Do not use the development server in a production environment.
   Use a production WSGI server instead.
 * Debug mode: on
 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
 * Restarting with stat
: No such file or directory

أعتقد أيضًا أن إجراء تغيير يعمل فقط على توزيعة Linux واحدة ولكن يكسر الباقي لا يبدو مثالياً. يبدو أن جعل الملفات غير قابلة للتنفيذ هو الحل المناسب ، لكن هذا لا يزال يشعرني بالكسر.

@ penner42 حاول #! / usr / bin / env python

root<strong i="7">@4541ebd677e0</strong>:/usr/src/app# ls -la /usr/local/bin/python3
lrwxrwxrwx 1 root staff 9 Mar  4 23:40 /usr/local/bin/python3 -> python3.6
root<strong i="8">@4541ebd677e0</strong>:/usr/src/app# ls -la /usr/local/bin/python 
lrwxrwxrwx 1 root staff 7 Mar  4 23:40 /usr/local/bin/python -> python3

ربما ليس لديك رابط رمزي في python3

نفس النتيجة. يوجد رابط python3 الرمزي ، ويعمل فقط تشغيل /usr/bin/env python3 أو /usr/bin/env python من قذيفة.

يعطي FWIW ، Docker هذا التحذير عند البناء.
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

استخدم الأمر flask run .

FROM python:3.7-alpine
WORKDIR /app
ENV FLASK_ENV development
ENV FLASK_APP example
EXPOSE 5000
RUN ["pip", "install", "flask"]
CMD ["flask", "run", "-h", "0.0.0.0"]

docker run --rm -p 5000:5000 -v $(pwd):/app flask/example:latest

هل كان البرنامج التعليمي الموجود على https://docs.docker.com/compose/gettingstarted/ يستخدم للعمل على Windows 7؟
هل هذا التغيير الأخير هو سبب ظهور خطأ مشابه أثناء محاولة تشغيل المثال:

$ docker-compose up
Creating composetest_web_1   ... done
Creating composetest_redis_1 ... done
Attaching to composetest_web_1, composetest_redis_1
redis_1  | 1:C 27 Mar 2019 17:29:12.746 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1  | 1:C 27 Mar 2019 17:29:12.746 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=1, just started
redis_1  | 1:C 27 Mar 2019 17:29:12.747 # Warning: no config file specified, using the default config. In order to specify a config file use redis-ser
ver /path/to/redis.conf
redis_1  | 1:M 27 Mar 2019 17:29:12.757 * Running mode=standalone, port=6379.
redis_1  | 1:M 27 Mar 2019 17:29:12.757 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to th
e lower value of 128.
redis_1  | 1:M 27 Mar 2019 17:29:12.758 # Server initialized
redis_1  | 1:M 27 Mar 2019 17:29:12.758 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issu
e add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
web_1    |  * Serving Flask app "app" (lazy loading)
web_1    |  * Environment: production
web_1    |    WARNING: Do not use the development server in a production environment.
web_1    |    Use a production WSGI server instead.
web_1    |  * Debug mode: on
web_1    |  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
web_1    |  * Restarting with stat
web_1    | Traceback (most recent call last):
web_1    |   File "app.py", line 32, in <module>
web_1    |     app.run(host="0.0.0.0", debug=True)
web_1    |   File "/usr/local/lib/python3.4/site-packages/flask/app.py", line 943, in run
web_1    |     run_simple(host, port, self, **options)
web_1    |   File "/usr/local/lib/python3.4/site-packages/werkzeug/serving.py", line 988, in run_simple
web_1    |     run_with_reloader(inner, extra_files, reloader_interval, reloader_type)
web_1    |   File "/usr/local/lib/python3.4/site-packages/werkzeug/_reloader.py", line 332, in run_with_reloader
web_1    |     sys.exit(reloader.restart_with_reloader())
web_1    |   File "/usr/local/lib/python3.4/site-packages/werkzeug/_reloader.py", line 176, in restart_with_reloader
web_1    |     exit_code = subprocess.call(args, env=new_environ, close_fds=False)
web_1    |   File "/usr/local/lib/python3.4/subprocess.py", line 534, in call
web_1    |     with Popen(*popenargs, **kwargs) as p:
web_1    |   File "/usr/local/lib/python3.4/subprocess.py", line 856, in __init__
web_1    |     restore_signals, start_new_session)
web_1    |   File "/usr/local/lib/python3.4/subprocess.py", line 1464, in _execute_child
web_1    |     raise child_exception_type(errno_num, err_msg)
web_1    | OSError: [Errno 8] Exec format error
composetest_web_1 exited with code 1

فعلت نفس البرنامج التعليمي ووجدت نفس المشكلة. هذه ثابتة بالنسبة لي.

لقد أضفت shebang التالي إلى أعلى البرنامج النصي الخاص بي app.py

#!/usr/local/bin/python3

مما تسبب بعد ذلك في مشاكل الإذن. ثم أضفت ما يلي إلى Dockerfile قبل CMD

RUN chmod 644 app.py

من فضلك يمكن لأي شخص تحديث البرنامج التعليمي (https://docs.docker.com/compose/gettingstarted/)
لتضيف

RUN chmod 644 app.py

تم اقتراح التغييرات في البرنامج التعليمي Docker Compose في https://github.com/docker/docker.github.io/pull/8609.

ثابت في الأداة 0.15.5.