من "بدء التشغيل" إلى آلاف الخوادم في عشرات مراكز البيانات. كيف طاردنا نمو البنية التحتية لينكس

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

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

بشكل عام ، يمكننا القول أن فريقنا يوفر منتجين للشركة. الأول هو البنية التحتية. يجب أن يذهب البريد ، ويجب أن يعمل DNS ، ويجب أن تسمح لك وحدات التحكم بالمجال بالدخول إلى الخوادم التي يجب ألا تقع. مشهد تكنولوجيا المعلومات للشركة ضخم! هذه أنظمة مهمة للأعمال والرسالة ، ومتطلبات إمكانية الوصول للبعض هي 2،99,999. المنتج الثاني هو الخوادم نفسها ، المادية والافتراضية. يجب مراقبة الموجود منها ، ويتم تسليم الجديد بانتظام للعملاء من العديد من الإدارات. في هذه المقالة ، أود التركيز على كيفية تطويرنا للبنية التحتية المسؤولة عن دورة حياة الخوادم.

بداية رحلة

في بداية الرحلة ، كانت مجموعتنا التكنولوجية تبدو كما يلي:
OS CentOS 7
وحدات تحكم مجال FreeIPA
أتمتة - أنسبل (+ برج) ، الإسكافي

كل هذا كان يقع في 3 مجالات موزعة على عدة مراكز بيانات. في مركز بيانات واحد - أنظمة مكتبية ومواقع اختبار ، وفي الباقي - PROD.

بدا إنشاء الخوادم في مرحلة ما على النحو التالي:

نموذج CentOS VM ضئيل والحد الأدنى هو /etc/resolv.conf الصحيح ، والباقي يأتي عبر Ansible.

CMDB - إكسل.

إذا كان الخادم ماديًا ، فبدلاً من نسخ الجهاز الظاهري ، تم تثبيت نظام التشغيل عليه باستخدام Cobbler - تتم إضافة عناوين MAC للخادم الهدف إلى تكوين Cobbler ، ويتلقى الخادم عنوان IP عبر DHCP ، ثم نظام التشغيل يسكب.

في البداية ، حاولنا القيام بنوع من إدارة التكوين في Cobbler. ولكن مع مرور الوقت ، بدأ هذا في جلب مشاكل مع إمكانية نقل التكوينات إلى كل من مراكز البيانات الأخرى وكود Ansible لإعداد جهاز افتراضي.

كان ينظر إلى Ansible في ذلك الوقت من قبل العديد منا على أنه امتداد Bash مناسب ولم يبخل على التركيبات باستخدام shell ، sed. بشكل عام ، Bashsible. أدى هذا في النهاية إلى حقيقة أنه إذا لم يعمل كتاب التشغيل لسبب ما على الخادم ، فسيكون من الأسهل حذف الخادم وإصلاح دفتر اللعب ولفه مرة أخرى. في واقع الأمر ، لم يكن هناك إصدار للنصوص ، وإمكانية نقل التكوينات أيضًا.

على سبيل المثال ، أردنا تغيير بعض التهيئة على جميع الخوادم:

1. نقوم بتغيير التكوين على الخوادم الموجودة في المقطع المنطقي / مركز البيانات. في بعض الأحيان ليس في يوم واحد - لا تسمح لك متطلبات التوفر وقانون الأعداد الكبيرة بتطبيق جميع التغييرات مرة واحدة. ومن المحتمل أن تكون بعض التغييرات مدمرة وتتطلب إعادة تشغيل أي شيء - من الخدمات إلى نظام التشغيل نفسه.
2. التثبيت في أنسبل
3. التثبيت في الإسكافي
4. كرر N مرات لكل جزء منطقي / مركز بيانات

لكي تتم جميع التغييرات بسلاسة ، يجب أخذ العديد من العوامل في الاعتبار ، وتحدث التغييرات طوال الوقت.

• إعادة هيكلة الكود غير المألوف ، ملفات التكوين
• تغيير أفضل الممارسات الداخلية
• التغييرات بعد تحليل الحوادث / الحوادث
• تغيير معايير الأمان الداخلية والخارجية. على سبيل المثال ، يتم تحديث PCI DSS بمتطلبات جديدة كل عام.

نمو البنية التحتية وبداية الرحلة

زاد عدد الخوادم / المجالات المنطقية / مراكز البيانات ، ومعها زاد عدد الأخطاء في التكوينات. في مرحلة ما ، توصلنا إلى ثلاثة اتجاهات نحتاج في اتجاهها إلى تطوير إدارة التكوين:

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

يبقى لإضافة زوج من الأدوات.

لقد اخترنا GitLab CE كمستودع للكود ، ليس أقله لوحدات CI / CD المدمجة.

قبو من الأسرار - Hashicorp Vault ، بما في ذلك. لواجهة برمجة التطبيقات الرائعة.

تكوينات الاختبار والأدوار غير المرئية - جزيء + Testinfra. تسير الاختبارات بشكل أسرع إذا قمت بالاتصال بميتوجين غير مرغوب فيه. بالتوازي مع ذلك ، بدأنا في كتابة CMDB الخاص بنا ومنسق للنشر التلقائي (في الصورة أعلاه Cobbler) ، لكن هذه قصة مختلفة تمامًا ، والتي سيخبرنا عنها زميلي والمطور الرئيسي لهذه الأنظمة في المستقبل.

اختيارنا:

جزيء + Testinfra
أنسبل + برج + AWX
عالم الخوادم + DITNET (تطوير خاص)
شراب مسكر
عداء Gitlab + GitLab
هاشكورب قبو

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

• نسخ الخوادم من الصورة الذهبية شرير!من العيوب الرئيسية - أنت لا تعرف بالضبط حالة الصور الآن ، وأن جميع التغييرات ستظهر على جميع الصور في جميع مزارع المحاكاة الافتراضية.
• احتفظ بملفات التكوين الافتراضية عند الحد الأدنى واتفق مع الأقسام الأخرى على أنك مسؤول عن ملفات النظام الرئيسيةعلى سبيل المثال:
  1. اترك /etc/sysctl.conf فارغًا ، يجب أن تكون الإعدادات فقط في /etc/sysctl.d/. الافتراضي الخاص بك في ملف واحد ، مخصص للتطبيق في ملف آخر.
  2. استخدم ملفات التجاوز لتحرير وحدات النظام.
• قم بتصميم جميع التكوينات ووضعها في مجملها ، إن أمكن ، بدون sed ومثيلاتها في قواعد اللعبة
• إعادة بناء كود نظام إدارة التكوين:
  1. قسّم المهام إلى كيانات منطقية وأعد كتابة المتراصة إلى أدوار
  2. استخدم النكام! أنسبل-لينت ، يامل لينت ، إلخ
  3. غير نهجك! لا bashsible. وصف حالة النظام
• لجميع أدوار Ansible ، تحتاج إلى كتابة الاختبارات في الجزيء وإنشاء تقارير مرة واحدة يوميًا.
• في حالتنا ، بعد إعداد الاختبارات (التي يوجد منها أكثر من 100) ، تم العثور على حوالي 70000 خطأ. ثابت لبضعة أشهر.

تنفيذنا

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

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

هناك أيضًا العديد من الخيارات لإنشاء الخوادم. لقد انتهينا من اختيار نصوص بيثون مخصصة. ولـ CI ansible:

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

هذا ما توصلنا إليه ، يستمر النظام في العيش والتطور.

• 17 دورًا لا يمكن تصديقه لإعداد الخادم. تم تصميم كل من الأدوار لحل مهمة منطقية منفصلة (التسجيل ، والتدقيق ، وتفويض المستخدم ، والمراقبة ، وما إلى ذلك).
• اختبار الدور. جزيء + اختبار الأشعة تحت الحمراء.
• التطوير الذاتي: CMDB + Orchestrator.
• وقت إنشاء الخادم هو حوالي 30 دقيقة ، وهو آلي ولا يعتمد عمليًا على قائمة انتظار المهام.
• نفس الحالة / تسمية البنية التحتية في جميع القطاعات - كتيبات اللعب ، والمستودعات ، وعناصر المحاكاة الافتراضية.
• تحقق يوميًا من حالة الخوادم مع إنشاء تقارير عن التناقضات مع المعيار.

آمل أن تكون قصتي مفيدة لأولئك الذين هم في بداية الرحلة. ما هي مكدس الأتمتة الذي تستخدمه؟

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