يبلغ النص الكامل 4955 كلمة والمدة المقدرة للدراسة 25 دقيقة

المصدر: أونسبلاش

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

ستخبرك هذه المقالة كيفية إضافتها إلى مشروع Python!

هذا هو مستودعي ، الذي يحتوي على شفرة المصدر الكاملة والوثائق: https://github.com/MartinHeinz/python-project-blueprint

حاوية Docker قابلة للتصحيح من أجل التنمية

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

من أجل تسهيل تصحيح الصورة ، تحتاج إلى صورة أساسية ، والتي تتضمن جميع الأدوات التي قد تحتاجها لتصحيح الأخطاء ، مثل bash ، vim ، netcat ، wget ، cat ، find ، grep ، إلخ.

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

ربما لاحظت أنني اخترت صورة محددة للغاية: أغلقت إصدار Python ونسخة دبيان. هذا مقصود لأننا نريد تقليل احتمالية "الفساد" الناتج عن إصدارات أحدث ، وربما غير متوافقة من Python أو Debian.

المصدر: تيك كرانش

يمكن استخدام النسخ المطابق القائم على جبال الألب بدلاً من ذلك. ومع ذلك ، قد يسبب هذا بعض المشاكل لأنه يستخدم musllibc بدلاً من glibc المعتمد على Python. لذلك ، إذا قررت اختيار هذا التكوين ، ضع ذلك في الاعتبار.

أما بالنسبة لسرعة البناء ، فسوف نستخدم البناء متعدد المراحل لتخزين أكبر عدد ممكن من الطبقات. وبهذه الطريقة ، يمكنك تجنب تنزيل التبعيات والأدوات مثل gcc وجميع المكتبات التي يطلبها التطبيق (في متطلبات ..txt).

نظرًا لأن الخطوات المطلوبة لتنزيل هذه الأدوات وتثبيتها لا يمكن تخزينها مؤقتًا في صورة البرنامج قيد التشغيل النهائي ، سنستخدم الثعبان المذكور أعلاه: 3.8.1-buster لإنشاء صورة أساسية مخصصة تحتوي على جميع الأدوات اللازمة ، وبالتالي تحسين سرعة المعالجة.

بعد قولي هذا ، دعنا نلقي نظرة على ملف Dockerfile:

# dev.Dockerfile FROMpython: 3.8.1-buster AS builder RUN apt-get update && apt-get install -y - no-install-توصي --yes python3-venv gcclibpython3-dev && \ python3 -m venv / venv && \ / venv / bin / pip تثبيت - upgradepip من باني ASbuilder-venv COPYrequirements.txt /requirements.txt RUN / venv / bin / pipinstall -r /requirements.txt من باني- venv AStester نسخة. / التطبيق WORKDIR / التطبيق RUN / venv / bin / pytest FROMmartinheinz / python-3.8.1-buster-tools: أحدث عداء AS نسخة - من = tester / venv / venv COPY --from = tester / app / app WORKDIR / التطبيق نقطة الدخول رقم المستخدم 1001 اسم LABEL = {NAME} الإصدار LABELversion = {VERSION}

من المستند أعلاه ، يمكننا أن نرى أننا سننشئ 3 صور وسيطة ، ثم ننشئ الصورة النهائية قيد التشغيل. تُسمى الصورة الأولى أداة إنشاء ، وتقوم بتنزيل جميع المكتبات الضرورية اللازمة لإنشاء التطبيق النهائي ، بما في ذلك gcc وبيئة Python الظاهرية. بعد اكتمال التثبيت ، سيتم أيضًا إنشاء البيئة الافتراضية الفعلية للصورة التالية.

التالي هو صورة builder-venv ، التي تنسخ قائمة التبعيات (متطلبات.txt) إلى الصورة ثم تقوم بتثبيتها. هذه الصورة الوسيطة مطلوبة للتخزين المؤقت ، لأنه سيتم تثبيت المكتبة فقط عند تغيير المتطلبات. txt ، وإلا سيتم استخدام التخزين المؤقت فقط.

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

بالنسبة لصورة العداء ، نستخدم صورة مخصصة ، والتي تتضمن بعض الميزات الإضافية التي لم يتم العثور عليها في صور دبيان العادية ، مثل vim أو netcat. يمكنك العثور على هذه الصورة هنا على Docker Hub ، أو يمكنك التحقق من ملف Dockerfile البسيط هذا في الأساس.

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

الآن بعد أن تحتوي الصورة على جميع المصادر ، انتقل إلى الدليل حيث يوجد التطبيق واضبط ENTRYPOINT لتشغيل التطبيق عند بدء الصورة. قم بتعيين USER على 1001 لأسباب أمنية ، لأن أفضل الممارسات تخبرنا أنه لا يجب تشغيل الحاويات تحت المستخدم الجذر.

حدد السطران الأخيران تسمية المرآة. عند استخدام الأمر make للإشارة إلى الإنشاء والتشغيل ، سيتم استبدالها أو ملؤها ، كما سنرى لاحقًا.

المصدر: أونسبلاش

حاويات دوكر الأمثل للمنتجات

عند التحدث عن الصور على مستوى المنتج ، نريد التأكد من صغر حجمها وأمانها وسرعتها. الصورة الشخصية المفضلة لدي هي صورة Python في مشروع Distroless. إذن ما هو Distroless؟

يمكن وصفها على النحو التالي: في عالم مثالي ، سيستخدم الجميع من الصفر كصورة أساسية (أي صورة فارغة) لبناء صورتهم.

ولكن هذا ليس ما يريد معظم الناس القيام به لأنه يتطلب ثنائيات مرتبطة بشكل ثابت ، إلخ. هنا يأتي دور Distroless وهو عبارة عن خدش مصمم للجميع.

Distroless عبارة عن مجموعة من الصور التي تم إنشاؤها بواسطة Google والتي تحتوي على الحد الأدنى من المتطلبات التي يتطلبها التطبيق ، مما يعني أنه بدون هيكل ، سيقوم مدير الحزم أو أي أداة أخرى بتضخيم الصورة وإشارة الماسح الضوئي الأمني (مثل CVE) الضوضاء ، مما يزيد من صعوبة وضع القواعد.

بمعرفة المشكلة التي يجب حلها ، دعنا نلقي نظرة على ملف Dockerfile ... في الواقع ، ليست هناك حاجة لإجراء العديد من التغييرات هنا ، سطرين فقط:

# ملف المنتج # 1.صورة تغيير الخط البناء FROMdebian: باني سليم AS # ... # 17.خط التبديل إلى صورة كسوة FROMgcr.io/distroless/python3-debian10 عداء # ... بقية ملف Dockefile

كل ما يحتاج إلى تغيير هو الصورة الأساسية المستخدمة لبناء وتشغيل التطبيق!

لكن الفارق كبير: صورة التطوير الخاصة بنا هي 1.03 جيجا بايت ، وهذه الصورة 103 ميجا بايت فقط ، وهي مختلفة تمامًا!

أعلم أنك ستقول "لكن جبال الألب يمكن أن تصبح أصغر" نعم ، نعم ، لكن فرق الحجم ليس مهمًا جدًا. ستنتبه فقط لحجم الصورة عند تنزيل / تحميل الصورة ، وهو أمر غير شائع. عندما تعمل المرآة ، يكون الحجم غير مهم تمامًا. والأهم من الحجم هو الأمن ، وفي هذا الصدد ، فإن Distroless له بالتأكيد ميزة ، لأن Alpine (وهو بديل جيد) لديه العديد من الحزم الإضافية التي يمكن أن تزيد من سطح الهجوم.

المصدر: أونسبلاش

آخر شيء جدير بالذكر حول Distroless هو صورة التصحيح. وبالنظر إلى أن Distroless لا يحتوي على أي غلاف (ولا حتى sh) ، فإن هذا يجعل الأمر صعبًا للغاية عند الحاجة إلى تصحيح الأخطاء والتفتيش. لهذا السبب ، تحتوي جميع صور Distroless على إصدارات تصحيح.

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

تشغيل عامل الميناء --entrypoint = sh -tigcr.io/distroless/python3-debian10:debug

أمر واحد لجميع المواقف

بعد إعداد جميع ملفات Dockerfiles ، قد ترغب في استخدام Makefile لأتمتة ذلك! أول شيء يجب فعله هو إنشاء تطبيقات باستخدام Docker. لذلك ، من أجل بناء صورة تطوير ، يمكننا تنفيذ الأمر make build-dev لتشغيل الملفات المستهدفة التالية:

# ثنائي لبناء (الاسم الأساسي فقط). الوحدة: = مخطط # أين تدفع صورة عامل الميناء. التسجيل؟ = Docker.pkg.github.com / martinheinz / python-project-blueprint الصورة: = $ (REGISTRY) / $ (MODULE) # تستخدم إستراتيجية الإصدار هذه علامات git لتعيين سلسلة الإصدار TAG: = $ (وصف بوابة الصدفة - العلامات - دائمًا - القذرة) البناء: echo "\ n $ {BLUE} صورة BuildingDevelopment مع التصنيفات: \ n" echo "name: $ (MODULE)" echo "الإصدار: $ (TAG) $ {NC} \ n" sed \ -e's | {NAME} | $ (MODULE) | g '\ -e 's | {VERSION} | $ (TAG) | g' \ dev.Dockerfile | بناء عامل الميناء -t $ (صورة): $ (TAG) -f-.

يتم إنشاء الملف الهدف أولاً عن طريق استبدال اسم وملصق الصورة بملصق في أسفل ملف dev. Dockerfile. يتم إنشاء الملصق عن طريق تشغيل git description ثم بناء docker.

الخطوة التالية استخدم make build-prod VERSION = 1.0.0 لبناء نسخة الإنتاج:

بناء المنتج: echo "\ n $ {BLUE} إنتاج المباني بالصور: \ n" echo "name: $ (MODULE)" echo "الإصدار: $ (VERSION) $ {NC} \ n" sed \ -e's | {NAME} | $ (MODULE) | g '\ -e 's | {VERSION} | $ (VERSION) | g' \ prod.Dockerfile | docker build -t $ (IMAGE): $ (VERSION) -f- ..

هذا مشابه جدًا للملف الهدف السابق ، ولكن في المثال على الإصدار 1.0.0 ، سنقوم بتمرير الإصدار كمعلمة بدلاً من استخدام علامة git كإصدار.

عند تشغيل كل شيء في Docker ، في بعض الأحيان يجب تصحيحه في Docker. لهذا ، توجد الملفات الهدف التالية:

# مثال: جعل shell CMD = "-c" التاريخ >  ملف التاريخ " shell: build-dev echo "\ n $ {BLUE} جارٍ إطلاق غلاف في بيئة البناء الحاوية ... $ {NC} \ n" تشغيل @ docker \ -تي \ --rm \ - نقطه / بن / باش \ -u $$ (id -u): $$ (id -g) \ $ (IMAGE): $ (TAG) \ $ (كمد)

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

عندما تنتهي من الترميز وتريد دفع الصورة إلى سجل Docker ، يمكنك استخدام makepush VERSION = 0.0.2. دعونا نلقي نظرة على وظيفة الملف الهدف:

التسجيل؟ = Docker.pkg.github.com / martinheinz / python-project-blueprint دفع: بناء همز echo "\ n $ {BLUE} جارٍ دفع الصورة إلى GitHub Docker Registry ... $ {NC} \ n" dockerpush $ (IMAGE): $ (VERSION)

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

يتم استخدام الملف الهدف الأخير لتنظيف التحف Docker. يستخدم علامة الاسم المستبدلة بملفات Dockerfiles لتصفية والعثور على القطع الأثرية التي يجب حذفها:

تنظيف عامل الميناء: docker system prune -f --filter "label = name = $ (MODULE)"

CI / CD باستخدام إجراءات GitHub

ابدأ الآن في استخدام كل هذه الأوامر الملائمة لإنشاء إعدادات CI / CD. سنستخدم إجراءات GitHub وسجل حزمة GitHub لبناء خط الأنابيب (العمل) وتخزين الصورة. إذن ما هما هذين الشيئين؟

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

GitHub Package Registry هي خدمة استضافة حزم متكاملة تمامًا مع GitHub. يمكنه تخزين أنواع مختلفة من الحزم ، مثل أحجار الياقوت أو حزم npm. سنستخدمه لتخزين صور Docker.

إذا لم تكن على دراية بـ GitHub Package Registry وتريد معرفة المزيد من المعلومات ذات الصلة ، يمكنك التحقق من مشاركة مدونتي: https://martinheinz.dev/blog/6

المصدر: أونسبلاش

الآن ، من أجل استخدام GitHub Action ، تحتاج إلى إنشاء سير عمل ، والذي سيتم تنفيذه وفقًا للمشغل المحدد (على سبيل المثال ، الدفع إلى المستودع). عمليات سير العمل هذه هي ملفات YAML ، موجودة في دليل .github / مهام سير العمل في المستودع:

.github fl سير العمل بناء اختبار دفع

تسمى المهمة الأولى بناء ، والذي يتحقق مما إذا كان يمكن إنشاء التطبيق عن طريق تشغيل الأمر make build-dev. ولكن قبل تشغيله ، يقوم أولاً باسترداد المستودع من خلال إجراء عملية تسمى الخروج المنشورة على GitHub.

وظائف: اختبار: يعمل على: أحدث أوبونتو خطوات: -uses: إجراءات / الخروج @ v1 -uses: Actions / setup-python @ v1 مع: نسخة بيثون: "3.8" -name: تثبيت التبعيات تشغيل: | بيثون-م تثبيت نقطة - ترقية نقطة تثبيت نقطة -r متطلبات. txt -name: قم بإجراء اختبار Makefile تشغيل: إجراء اختبار -name: تثبيت Linters تشغيل: | تثبيت نقطة pylint نقطة تثبيت flake8 نقطة تثبيت اللصوص -name: تشغيل Linters تشغيل: جعل الوبر

الوظيفة الثانية أكثر تعقيدًا بقليل. يقوم بإجراء اختبارات ضد التطبيق و 3 linter (مدقق جودة الكود).

كما هو الحال مع العمل السابق ، نستخدم عملية checkout @ v1 للحصول على شفرة المصدر. بعد ذلك ، قم بتشغيل عملية أخرى منشورة تسمى setup-python @ v1 ، والتي ساعدت في إعداد بيئة python (يمكنك العثور على مزيد من المعلومات عنها هنا).

الآن بعد أن أصبح لديك بيئة python ، تحتاج إلى استخدام تبعيات التطبيق في المتطلبات. txt المثبتة بواسطة النقطة. عند هذه النقطة ، يمكنك الاستمرار في تشغيل الأمر make test ، والذي سيؤدي إلى تشغيل مجموعة Pytest. إذا نجح جناح الاختبار ، فسيستمر في تثبيت الوبر المذكورة أعلاه ، مثل pylint و flake8 و اللصوص. أخيرًا ، قم بتشغيل الأمر make lint ، والذي سيؤدي إلى تشغيل كل لنتر.

هذه هي عملية البناء / الاختبار بأكملها ، ولكن كيف ينبغي دفعها؟ إلق نظرة:

على: إدفع: العلامات: - "*" وظائف: إدفع: يعمل على: أحدث أوبونتو خطوات: -uses: إجراءات / الخروج @ v1 -name: تعيين env run: echo :: set-envname = RELEASE_VERSION :: $ (echo $ {GITHUB_REF: 10}) -name: قم بتسجيل الدخول إلى التسجيل run: echo "$ {{secrets.REGISTRY_TOKEN}}" | تسجيل دخول عامل الميناء docker.pkg.github.com -u $ {{github.actor}} - password-stdin -name: ادفع إلى GitHubPackage Registry الجري: make pushVERSION = $ {{env.RELEASE_VERSION}}

تحدد الأسطر الأربعة الأولى وقت تشغيل هذا العمل. نحدد أن العمل سيبدأ فقط عندما يتم دفع العلامة إلى المستودع (* في هذه الحالة ، يمكن أن يكون اسم العلامة المحدد أي نمط) ، لذلك لن يتم دفع صورة Docker إلى GitHub Package Registry في كل مرة يتم دفعها إلى المستودع ومع ذلك ، سيتم دفعه فقط إلى GitHub Package Registry عندما يتم دفع إصدار جديد من ملصق التطبيق المحدد.

الآن بعد أن أصبح لدينا الجزء الرئيسي من العمل ، يبدأ باسترداد شفرة المصدر وتعيين متغير البيئة لـ RELEASE_VERSION إلى علامة git المدفوعة. يتم ذلك من خلال وظيفة :: setenv المضمنة في إجراءات GitHub.

بعد ذلك ، يستخدم REGISTRY_TOKEN المخزن في أسرار المستودع لتسجيل الدخول إلى سجل Docker وتسجيل الدخول إلى المستخدم الذي بدأ سير العمل (github.actor). أخيرًا ، في السطر الأخير ، يقوم بتشغيل الأمر push ، الذي يقوم ببناء صورة الإنتاج ويدفعها إلى التسجيل ، باستخدام تسمية git التي تم دفعها سابقًا كتسمية الصورة.

يمكن استرداد قائمة الرموز الكاملة هنا: https://github.com/MartinHeinz/python-project-blueprint/tree/master/.github/workflows

فحص جودة الرمز مع CodeClimate

أخيرًا وليس آخرًا ، يتم استخدام CodeClimate و SonarCloud أيضًا لإضافة اختبارات جودة التعليمات البرمجية. سيتم تشغيل هذه مع عمل الاختبار الموضح أعلاه. لذلك ، نضيف إليها بضعة أسطر:

# اختبار ، لينت ... -name: أرسل التقرير إلى CodeClimate تشغيل: | تصدير GIT_BRANCH = "$ {GITHUB_REF / refs \ / heads \ //}" curl -Lhttps: //codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 >  . / cc-test-reporter chmod + x ./cc-test-reporter ./cc-test-reporter format-cover -t Cover.py Cover.xml ./cc-test-reporter تحميل-تغطية -r "$ {{secrets.CC_TEST_REPORTER_ID}}" -الاسم: SonarCloudscanner الاستخدامات: sonarsource / sonarcloud-github-action @ master env: GITHUB_TOKEN: {{secrets.GITHUB_TOKEN}} دولار SONAR_TOKEN: {{secrets.SONAR_TOKEN}} دولار

بدءًا من CodeClimate ، قم أولاً بتصدير متغير GIT_BRANCH ، ثم استخدم متغير البيئة GITHUB_REF لاسترداده. ثانيًا ، قم بتنزيل برنامج تقرير اختبار CodeClimate واجعله قابلاً للتنفيذ. ثم استخدمه لتنسيق تقرير التغطية الذي تم إنشاؤه بواسطة مجموعة الاختبار وإرساله في السطر الأخير إلى CodeClimate باستخدام معرف مراسل الاختبار ، والذي يتم تخزينه في أسرار المستودع.

بالنسبة إلى SonarCloud ، نحتاج إلى إنشاء ملف sonar-project.properties في المستودع كما هو موضح أدناه (يمكن العثور على القيم في الملف في الركن الأيمن السفلي من لوحة القيادة SonarCloud):

.orporation = martinheinz-github sonar.projectKey = MartinHeinz_python-project-blueprint sonar.sources = مخطط

بالإضافة إلى ذلك ، ما عليك سوى استخدام sonarcloud-github-action الحالي للقيام بكل العمل من أجلنا. كل ما عليك فعله هو توفير رمزين مميزين: رمز GitHub المميز (الموجود في المستودع افتراضيًا) ورمز SonarCloud (المتوفر من موقع SonarCloud الإلكتروني).

ملاحظة: للحصول على خطوات حول كيفية الحصول على جميع الرموز والمفاتيح أعلاه وإعدادها ، يرجى الرجوع إلى ملف README: https://github.com/MartinHeinz/python-project-blueprint/blob/master/README.md

المصدر: أونسبلاش

من خلال الأدوات والتكوين والرمز أعلاه ، يمكنك إنشاء وأتمتة جميع جوانب مشروع Python التالي. جربه الآن!

اترك تعليقا

دعونا نتشارك في السلع الجافة لتعلم وتطوير الذكاء الاصطناعي معًا

إذا أعيد طبعه ، يرجى ترك رسالة في الخلفية واتباع مواصفات إعادة الطباعة