السؤال الأول في أي مشروع لتشغيل Windchill في حاويات ليس أي عنقود نستخدم، بل ما الذي ينبغي أن تحتويه الصورة. إن أحسنتم الإجابة، صار كل ما يليها بسيطًا، من خطوط النشر إلى التراجع. وإن أخطأتم، انتهى بكم الأمر إلى صورة لكل بيئة، والانحراف نفسه الذي عانيتموه على الأجهزة الافتراضية.
القاعدة: البناء مرة واحدة، والإعداد عند النشر
ينبغي أن تكون الصورة متطابقة في الاختبار والإنتاج. وكل ما يختلف بين البيئات يُحقن عند إقلاع الحاوية، ولا يُدمج في الصورة أبدًا.
داخل الصورة:
- تثبيت Windchill بإصدار ومستوى تحديثات معروفين
- تخصيصاتكم المجمَّعة، التي بناها خط النشر من commit موسوم
- بيئة التشغيل التي يتطلبها الإصدار، ولا شيء غيرها
- سكربت إقلاع يقرأ الإعدادات من البيئة وينتظر جاهزية الخدمات التي يعتمد عليها
خارج الصورة:
- أسماء المضيفين والعناوين والخصائص الخاصة بكل موقع، وتُمرَّر كمتغيرات بيئة أو ملفات مركّبة
- كلمات المرور والمفاتيح والشهادات، وتُقرأ من مخزن أسرار مثل Azure Key Vault
- مستودعات الملفات والسجلات وغيرها من البيانات التي يجب أن تبقى بعد زوال الحاوية، على وحدات تخزين دائمة
- قاعدة البيانات، التي تعمل كخدمة مُدارة أو على خوادم مخصصة
صورة واحدة، وأدوار متعددة
Windchill ليس عملية واحدة. فواجهات الويب الأمامية، وخوادم Method Server، وطوابير المعالجة في الخلفية، والبحث، لكل منها مهمة مختلفة واحتياجات توسع مختلفة. نبني صورة واحدة ونشغّلها بأدوار مختلفة، فنضمن أن كل مكوّن يشغّل الشيفرة نفسها.
فحوص صحة تقول الحقيقة
لا يستطيع Kubernetes استبدال حاوية معطّلة إلا إذا عرف أنها معطّلة. ولا يكفي أن تكون العملية قيد التشغيل: فحوص الجاهزية لدينا تستدعي التطبيق وتتأكد من قدرته على خدمة طلب، فلا تصل حركة المرور إلا إلى الـ pods الجاهزة فعلًا.
وسم الصور كالإصدارات
تُوسم كل صورة برقم الإصدار والـ commit الذي بُنيت منه، ولا يُكتفى أبدًا بوسم latest. فحين يقع خلل في الثالثة فجرًا، يكون السؤال الأول: ما الذي يعمل الآن؟ وينبغي أن يجيب الوسم عن ذلك.
قبل أن تبدأوا
تحققوا من موقف PTC من دعم النشر في حاويات لإصداركم، وخطّطوا لطريقة النسخ الاحتياطي لقاعدة البيانات ومستودعات الملفات واستعادتها. فالحاويات تغيّر طريقة نشر Windchill، لكنها لا تغيّر ما يحتاج إليه ليبقى آمنًا.