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

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







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



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



بداية المسار



في بداية المسار ، بدا كومة التكنولوجيا الخاصة بنا كما يلي:

OS CentOS 7

وحدات تحكم المجال FreeIPA

Automation - Ansible (+ Tower) ، Cobbler



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



في وقت ما ، بدا إنشاء الخوادم على







النحو التالي : في قالب VM CentOS الأدنى والحد الأدنى المطلوب ، مثل /etc/resolv.conf الصحيح ، يأتي الباقي من خلال Ansible.



CMDB - Excel.



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



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



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



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

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

لكي تتم جميع التغييرات بسلاسة ، يجب مراعاة العديد من العوامل ، وتحدث التغييرات باستمرار.

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

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



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

1. التشغيل الآلي. بقدر الإمكان ، ينبغي تجنب العامل البشري في العمليات المتكررة.
2. . , . . – , .
3. configuration management.

يبقى لإضافة بعض الأدوات.



لقد اخترنا GitLab CE كمخزن رمز خاص بنا ، على الأقل لوحدات CI / CD المدمجة.



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



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



اختيارنا:



Molecule + Testinfra

Ansible + Tower + AWX Server

World + DITNET (داخل المنزل)

Cobbler

Gitlab + عداء

GitLab Hashicorp Vault









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

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

تنفيذنا



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







بعد أن وصل التغيير ، تم إطلاق 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 دورًا غير مرئي لتكوين الخادم. تم تصميم كل من الأدوار لحل مهمة منطقية منفصلة (التسجيل ، والتدقيق ، وتفويض المستخدم ، والمراقبة ، وما إلى ذلك).
• اختبار الأدوار. جزيء + TestInfra.
• التنمية الخاصة: CMDB + Orchestrator.
• وقت إنشاء الخادم ~ 30 دقيقة ، مؤتمتة ومستقلة عمليا من قائمة انتظار المهام.
• نفس الدولة / تسمية البنية التحتية في جميع الأقسام - كتب اللعب والمستودعات وعناصر المحاكاة الافتراضية.
• فحص يومي لحالة الخوادم مع توليد تقارير عن التناقضات مع المعيار.

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