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

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

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

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

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

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

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

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

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

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

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

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

إدارة الأسرار

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

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

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

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

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

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

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

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

أرز. 2. إدارة الأسرار.

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

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

بدلاً من Ansible، يمكن استخدام Chef وPuppet وSaltStack. لقد اخترنا Ansible بناءً على عدة معايير.

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

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

يتم حل نصيب الأسد من مثل هذه القضايا بواسطة Red Hat برج أنسبل، أو مشروعه المنبع مفتوح المصدر Ansible AWX. ولهذا السبب فضلناها للعميل.

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

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

أرز. 3. إدارة التكوين.

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

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

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

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

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

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

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

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

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

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

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

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

أرز. 5. التحقق من وجود تناقضات في التكوين في Ansible AWX.

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

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

أرز. 6. إدارة الاختبار.

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

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

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

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

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

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

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

المصدر: www.habr.com