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





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



كان تشغيل الخوادم الجديدة مرتبطًا بشدة بالموعد النهائي. وسيؤدي نقله إلى تعريض كل من شحن مليار هدية وهجرة الأنظمة للخطر. حتى الفريق المكون من سانتا كلوز وسانتا كلوز لم يتمكن من تغيير التاريخ - يمكن نقل نظام SAP لإدارة المستودعات مرة واحدة فقط في السنة. من 31 ديسمبر إلى 1 يناير ، توقفت مستودعات التجزئة الضخمة ، التي يبلغ مجموعها 20 ملعبًا لكرة القدم ، عن العمل لمدة 15 ساعة. وهذه هي الفترة الزمنية الوحيدة التي يتحرك فيها النظام. لم يكن لدينا الحق في ارتكاب خطأ بدخول السيرفرات.



دعني أوضح على الفور: تعكس قصتي مجموعة الأدوات وعملية إدارة التكوين التي يستخدمها فريقنا.



يتكون مجمع إدارة التكوين من عدة مستويات. المكون الرئيسي هو نظام CMS. في الاستغلال الصناعي ، سيؤدي غياب أحد المستويات حتما إلى معجزات غير سارة.

إدارة تثبيت نظام التشغيل

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



بمساعدة هذا النظام ، تلقينا معيارًا ومناسبًا لمزيد من حالات التشغيل الآلي للخوادم التي تعمل بنظام التشغيل. عندما تم إرسالهم ، تلقوا مجموعة صغيرة من المستخدمين المحليين ومفاتيح SSH العامة ، بالإضافة إلى تكوين نظام تشغيل ثابت. يمكن ضمان إدارة الخوادم من خلال CMS وتأكدنا من عدم وجود مفاجآت "أقل" على مستوى نظام التشغيل.



الهدف الأقصى لنظام إدارة التثبيت هو تكوين الخوادم تلقائيًا من مستوى BIOS / البرنامج الثابت إلى نظام التشغيل. يعتمد الكثير على مهام الأجهزة والتكوين. بالنسبة للمعدات غير المتشابهة ، ضع في اعتبارك واجهة برمجة تطبيقات REDFISH... إذا كانت جميع الأجهزة من بائع واحد ، فغالبًا ما يكون من الأنسب استخدام أدوات الإدارة الجاهزة (على سبيل المثال ، مضخم HP ILO ، و DELL OpenManage ، وما إلى ذلك).



لتثبيت نظام التشغيل على الخوادم الفعلية ، استخدمنا Cobbler المعروف ، والذي يحدد مجموعة من ملفات تعريف التثبيت المنسقة مع خدمة الصيانة. عند إضافة خادم جديد إلى البنية التحتية ، يقوم المهندس بربط عنوان MAC الخاص بالخادم بالملف الشخصي المطلوب في Cobbler. عند التمهيد الأول عبر الشبكة ، تلقى الخادم عنوانًا مؤقتًا ونظام تشغيل جديدًا. ثم تم نقله إلى عنوان VLAN / IP المستهدف واستمر في العمل هناك. نعم ، يستغرق تغيير شبكات VLAN وقتًا ويتطلب التنسيق ، ولكنه يوفر حماية إضافية ضد التثبيت العرضي للخادم في بيئة الإنتاج.



قمنا بإنشاء خوادم افتراضية على أساس القوالب المعدة باستخدام HashiCorp Packer. كان السبب هو نفسه: لمنع الأخطاء البشرية المحتملة عند تثبيت نظام التشغيل. ولكن ، على عكس الخوادم الفعلية ، تسمح لك Packer بعدم استخدام PXE وتمهيد الشبكة وتغيير VLAN. هذا جعل إنشاء خوادم افتراضية أسهل وأبسط.





الشكل: 1. إدارة تركيب أنظمة التشغيل.

الإدارة السرية

يحتوي أي نظام إدارة تكوين على بيانات يجب إخفاؤها عن المستخدمين العاديين ، ولكنها ضرورية لإعداد الأنظمة. هذه هي كلمات مرور المستخدمين المحليين وحسابات الخدمة ، ومفاتيح الشهادات ، ومختلف رموز API ، وما إلى ذلك ، وعادة ما يطلق عليها "الأسرار".



إذا لم يتم تحديد مكان وكيفية تخزين هذه الأسرار منذ البداية ، فعندئذٍ ، بناءً على شدة متطلبات IS ، من المحتمل أن تكون طرق التخزين التالية:

• مباشرة في رمز إدارة التكوين أو في الملفات الموجودة في المستودع ؛
• في أدوات إدارة التكوين المتخصصة (على سبيل المثال ، Ansible Vault) ؛
• في أنظمة CI / CD (Jenkins / TeamCity / GitLab / ، إلخ) أو في أنظمة إدارة التكوين (Ansible Tower / Ansible AWX) ؛
• كما يمكن نقل الأسرار إلى "التحكم اليدوي". على سبيل المثال ، يتم وضعها في مكان متفق عليه ، ثم يتم استخدامها بواسطة أنظمة إدارة التكوين ؛
• مجموعات مختلفة مما ورد أعلاه.

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



استخدمنا HashiCorp Vault المركزي. سمح لنا هذا بـ:

• حافظ على الأسرار آمنة. يتم تشفيرها ، وحتى إذا تمكن شخص ما من الوصول إلى قاعدة بيانات Vault (على سبيل المثال ، من خلال استعادتها من نسخة احتياطية) ، فلن يتمكن من قراءة الأسرار المخزنة هناك ؛
• . «» ;
• . Vault;
• « » . , , . .
• , ;
• , , ..

الآن دعنا ننتقل إلى نظام المصادقة والتفويض المركزي. يمكنك الاستغناء عنها ، لكن إدارة المستخدمين في العديد من الأنظمة ذات الصلة أمر تافه للغاية. لقد قمنا بتكوين المصادقة والتفويض من خلال خدمة LDAP. وإلا ، فسيتعين على Vault نفسه إصدار وحفظ سجلات رموز المصادقة المميزة للمستخدمين بشكل مستمر. وسيتحول حذف المستخدمين وإضافتهم إلى مهمة "هل أنشأت / حذفت UZ هذا في كل مكان؟"



نضيف مستوى آخر إلى نظامنا: إدارة الأسرار والمصادقة / التفويض المركزي:





الشكل: 2. إدارة الأسرار.

إدارة التكوين

وصلنا إلى جوهر - إلى نظام CMS. في حالتنا ، هذه مجموعة من Ansible و Red Hat Ansible AWX.



الشيف ، الدمية ، SaltStack يمكن أن يتصرف بدلاً من Ansible. اخترنا أنسبل لعدة معايير.

• أولاً ، إنها براعة. مجموعة الوحدات الجاهزة للتحكم مثيرة للإعجاب . وإذا لم يكن لديك ما يكفي ، فيمكنك البحث على GitHub و Galaxy.
• ثانيًا ، ليست هناك حاجة لتركيب وصيانة عوامل على المعدات الخاضعة للرقابة ، لإثبات أنها لا تتداخل مع الحمولة ، ولتأكيد عدم وجود "إشارات مرجعية".
• ثالثًا ، لدى Ansible عائق منخفض للدخول. سيقوم المهندس المختص بكتابة كتاب قواعد اللعبة حرفياً في اليوم الأول من العمل مع المنتج.

لكن Ansible وحدها لم تكن كافية بالنسبة لنا في البيئة الصناعية. خلاف ذلك ، سيكون هناك العديد من المشاكل مع تقييد الوصول وتدقيق إجراءات المسؤولين. كيفية التفريق بين الوصول؟ بعد كل شيء ، يحتاج كل قسم إلى إدارة (قراءة - تشغيل كتاب اللعب Ansible) "الخاصة به" من الخوادم. كيف يمكنني السماح لموظفين محددين فقط بتشغيل كتيبات لعب Ansible معينة؟ أو كيف يمكن تتبع من أطلق كتاب التشغيل دون تشغيل العديد من KMs المحلية على خوادم وأجهزة Ansible؟



Red Hat Ansible Tower ، أو مشروع Ansible AWX المنبع المفتوح المصدر ، يحل نصيب الأسد من مثل هذه المشكلات . لذلك فضلناه على العميل.



ولمسة أخرى لصورة نظام CMS الخاص بنا. يجب تخزين دليل التشغيل في أنظمة إدارة مستودعات الكود. لدينا هذا GitLab CE .



لذلك ، تتم إدارة التكوينات نفسها بواسطة حزمة من Ansible / Ansible AWX / GitLab (انظر الشكل 3). بالطبع ، تم دمج AWX / GitLab مع نظام مصادقة موحد ، وتم دمج كتاب اللعب Ansible مع HashiCorp Vault. تدخل التكوينات إلى بيئة الإنتاج فقط من خلال Ansible AWX ، حيث يتم تعيين جميع "قواعد اللعبة": من وماذا يمكن تكوينه ، ومكان الحصول على رمز إدارة التكوين لنظام إدارة المحتوى ، وما إلى ذلك.





الشكل: 3. إدارة التكوين.

إدارة الاختبار

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



إذا لم يتم ذلك على الفور ، فإن الأدوار المكتوبة للتكوين ستتوقف عن الاحتفاظ بها وتعديلها ، أو ستتوقف عن العمل في الإنتاج. وعلاج هذا الألم معروف ، وقد أتى ثماره في هذا المشروع:

• يتم تغطية كل دور من خلال اختبارات الوحدة ؛
• يتم تشغيل الاختبارات تلقائيًا كلما حدث تغيير في كود إدارة التكوين ؛
• التغييرات في كود إدارة التكوين تدخل بيئة الإنتاج فقط بعد اجتياز جميع الاختبارات ومراجعة الكود بنجاح.

تطوير الكود وإدارة التكوين أكثر هدوءًا ويمكن التنبؤ به. لتنظيم الاختبار المستمر ، استخدمنا مجموعة أدوات GitLab CI / CD ، وأخذنا Ansible Molecule كإطار عمل لتنظيم الاختبارات .



لأي تغيير في رمز إدارة التكوين ، يستدعي GitLab CI / CD Molecule:

• يتحقق من صياغة الكود ،
• ترفع حاوية Docker ،
• يطبق الكود المعدل على الحاوية التي تم إنشاؤها ،
• يتحقق من دور العاطفة ويقوم بإجراء اختبارات لهذه الشفرة (الدقة هنا في مستوى الدور غير المرغوب فيه ، انظر الشكل 4).

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





الشكل: 4. الاختبار التلقائي للأدوار في GitLab CI / CD.



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



ونتيجة لذلك ، وبسبب التغييرات اليدوية ، تظهر التناقضات في التكوين على نفس نوع المعدات (على سبيل المثال ، على عقد مجموعة HA تكوين مختلف لإعدادات sysctl). أو يختلف التكوين الفعلي على الجهاز عن المحدد في كود CMS.



لذلك ، بالإضافة إلى الاختبار المستمر ، نتحقق من بيئات الإنتاج بحثًا عن الاختلافات في التكوين. لقد اخترنا الخيار الأبسط: تشغيل كود تكوين CMS في وضع "التشغيل الجاف" ، أي بدون تطبيق التغييرات ، ولكن مع إعلام بجميع التناقضات بين التكوين المخطط والحقيقي. لقد قمنا بتنفيذ ذلك من خلال تشغيل جميع كتب اللعب Ansible بشكل دوري مع خيار "--check" على خوادم الإنتاج. كما هو الحال دائمًا ، فإن Ansible AWX هي المسؤولة عن إطلاق دليل التشغيل وأهميته (انظر الشكل 5):





الشكل: 5. التحقق من وجود اختلافات في التكوين في Ansible AWX.



بعد عمليات التحقق ، ترسل AWX تقرير تناقض إلى المسؤولين. يدرسون تكوين المشكلة ثم يصلحونها من خلال قواعد اللعبة المعدلة. بهذه الطريقة نحافظ على التكوين في بيئة الإنتاج ويكون CMS دائمًا محدثًا ومتزامنًا. هذا يزيل "المعجزات" غير السارة عندما يتم تطبيق كود CMS على خوادم "الإنتاج".



لدينا الآن طبقة اختبار مهمة تتكون من Ansible AWX / GitLab / Molecule (الشكل 6).





الشكل: 6. إدارة الاختبار.



الصعب؟ أنا لا أجادل. لكن مجمع إدارة التكوين هذا أصبح إجابة شاملة للعديد من الأسئلة المتعلقة بأتمتة تكوين الخادم. الآن لدى بائع التجزئة دائمًا تكوين محدد بدقة للخوادم القياسية. لن تنسى CMS ، على عكس المهندس ، إضافة الإعدادات الضرورية وإنشاء المستخدمين وتنفيذ عشرات أو مئات الإعدادات المطلوبة.



لا توجد "معرفة سرية" في إعدادات الخوادم والبيئات اليوم. تنعكس جميع الميزات الضرورية في دليل التشغيل. لا مزيد من الإبداع والتعليمات الغامضة: " ضعها مثل Oracle العادية ، ولكن هناك تحتاج إلى تسجيل اثنين من إعدادات sysctl ، وإضافة المستخدمين باستخدام UID المطلوب. اسألوا الرجال من العملية ، فهم يعرفون ".



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



وبالطبع قمنا بتسريع إطلاق السيرفرات في الإنتاج من أيام قليلة إلى ساعات.



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



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



المؤلف: سيرجي أرتيموف ، مهندس قسم حلول DevOps في Jet Infosystems