كيف يُكتشف البناء

أيّ الملفات تُعدّ Dockerfile أو ملف Compose، وكيف يُعثر على المنفذ، وما يحدث حين يوجد أكثر من مرشّح أو لا يوجد أيّ مرشّح.

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

ما الذي يُقرأ

  • كل Dockerfile، في أي مجلّد.
  • ملفات Compose، وملف .env المجاور لكل منها.
  • ملفات YAML الأخرى التي تسمّي خدماتُها صورًا جاهزة. وهذه تُعرض على حدة، على أنها ملفات stack.

المجلّدات التي تحوي شيفرة الآخرين تُتخطّى: node_modules و vendor و .venv و venv و site-packages و bower_components و .terraform و __pycache__ و .git.

ما الذي يُعدّ Dockerfile

بأحرف كبيرة أو صغيرة، في أي مجلّد:

  • Dockerfile و Containerfile.
  • مع لاحقة: Dockerfile.worker و Dockerfile.prod.
  • مع بادئة: api.Dockerfile.
  • مع الاثنتين: api.Dockerfile.prod و web.Dockerfile.dev.

ويُقرأ الاسم لمعناه أيضًا. كلمة مثل dev أو local أو test أو ci أو staging أو prod أو production أو release تسمّي بيئة: طريقة ثانية لبناء التطبيق نفسه. وأي كلمة أخرى تسمّي خدمة: فـ Dockerfile.worker و api.Dockerfile تطبيقان مستقلّان.

ما الذي يُعدّ ملف Compose

compose.yaml و compose.yml و docker-compose.yaml و docker-compose.yml، بهذا الترتيب. يُقرأ واحد لكل مجلّد. والملفات الأخرى المجاورة له، وملفات التجاوز مثل docker-compose.override.yml أو compose.prod.yaml، لا تُطبَّق، ويقول الفحص ذلك.

كل خدمة فيها قسم build: تصبح تطبيقًا، يُبنى من Dockerfile والمجلّد اللذين يسمّيهما ذلك القسم. و Dockerfile الذي تستخدمه خدمة Compose لا يُعرض مرة ثانية بمفرده.

ومن خدمة كهذه يأخذ الفحص أيضًا environment الخاص بها، ومدخلات env_file الموجودة في المستودع، ومنفذها. والمتغيّرات التي تتوقّعها من جهازك تُسرد لتضبطها أنت، ولا تُخمَّن أبدًا.

بعض الأمور لا تنتقل، ويُذكر كل منها على الخدمة المعنيّة: وحدات التخزين، وفحص السلامة، ومعاملات البناء، وهدف البناء، وأكثر من نسخة واحدة، وتجاوز command أو entrypoint. والخدمة التي لا تختلف إلا بأمرها تُترك بلا تأشير لهذا السبب.

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

كيف يُعثر على المنفذ

بهذا الترتيب:

  1. ports أو expose في خدمة Compose: جهة الحاوية، وأول منفذ TCP.
  2. EXPOSE في Dockerfile، في مرحلته الأخيرة.
  3. إن غاب الاثنان، تُسأل الصورة المبنيّة بعد البناء. وهذا يلتقط أيضًا منفذًا تعلنه الصورة الأساسية.

المنفذ المكتشف يتبع الصورة: إن كشف بناء لاحق منفذًا آخر، انتقل التطبيق إليه. والمنفذ الذي تكتبه بنفسك لا يغيّره أي بناء.

الخدمة التي لا منفذ لها ويقول اسمها أو أمر تشغيلها worker أو consumer أو scheduler تُستورد كعامل خلفي: لا يُوجَّه إليها شيء ولا يمكن جعلها عامّة. ألغِ ذلك إن كانت تخدم حركة مرور فعلًا.

أكثر من مرشّح

الخدمات المختلفة يؤشَّر عليها كلّها. المستودع الذي فيه Dockerfile و Dockerfile.worker، أو api/Dockerfile و web/Dockerfile، يعطي تطبيقًا لكل واحد.

صيغ البيئات لا يؤشَّر عليها بجوار ملف مجرّد. مع Dockerfile و Dockerfile.dev، يُختار الملف المجرّد مسبقًا ويُعرض الآخر بلا تأشير، كي لا يشغّل النشر بناء تطوير بجوار البناء الحقيقي.

حين تسمّي كل وصفة بيئة، تكون الغلبة للإنتاج. مع api.Dockerfile.dev و api.Dockerfile.prod وبلا ملف مجرّد، يؤشَّر على المسمّى prod أو production أو release.

وفي ما عدا ذلك لا يؤشَّر على شيء وتختار أنت. ملفّان مسمّيان للإنتاج، أو dev و staging فقط، سؤال لا يستطيع الاسم حسمه.

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

المستودعات متعدّدة الخدمات

تطبيق واحد لكل Dockerfile ولكل خدمة Compose تُبنى، حتى 20 في الاستيراد الواحد. يُسمّى كل منها باسم مجلّده، أو باسم المستودع لملف في الجذر، مع إضافة الصيغة: shop-worker.

حين يُعثر على عدّة تطبيقات، تكون خاصّة ما لم يدلّ شيء على غير ذلك: التطبيق الوحيد في المستودع، وما ينشره Compose على المستضيف، والمجلّدات المسمّاة كواجهة أمامية (web و frontend و ui و app) تكون عامّة افتراضيًا.

حين لا يوجد Dockerfile

من مستودع، لا يُعرض شيء. يقول الفحص إنه لا يمكن نشر شيء بعد وما ينبغي إضافته: Dockerfile، أو ملف Compose فيه قسم build:. ولا يُخمَّن شيء من لغة الشيفرة.

في AI Studio الأمر مختلف. حين تنشر مشروعًا ليس فيه Dockerfile، يُكتب له واحد انطلاقًا من قائمة ملفات المشروع وملف تبعياته. ويُحفظ في المشروع كملف عادي، فتستطيع قراءته وتعديله وإيداعه. و Dockerfile الذي كتبته أنت لا يُستبدل أبدًا. وكتابة واحد تُحتسب استخدامًا للذكاء الاصطناعي. وإن تعذّرت كتابته، يتوقّف البناء ويقول إن Dockerfile مفقود.

كل شيء يمكن تجاوزه

أشّر على أي تطبيق أو ألغِ التأشير، وأعد تسميته، واضبط منفذه، واجعله عامًّا أو خاصًّا، وأضف متغيّرات وأسرارًا قبل النشر.

إن فات الفحصَ Dockerfile، أو احتاج إلى مجلّد بناء مختلف، فأضفه بمساره. ويُقرأ مثل البقية.

ماذا تقرأ بعد ذلك