🥇एक "स्टार्टअप" से लेकर एक दर्जन डेटा केंद्रों में हजारों सर्वर तक। हमने लिनक्स बुनियादी ढांचे के विकास का पीछा कैसे किया

यदि आपका आईटी बुनियादी ढांचा बहुत तेज़ी से बढ़ता है, तो देर-सबेर आपके सामने एक विकल्प होगा: इसका समर्थन करने के लिए मानव संसाधनों को रैखिक रूप से बढ़ाएं या स्वचालन शुरू करें। कुछ बिंदु तक, हम पहले प्रतिमान में रहते थे, और फिर इन्फ्रास्ट्रक्चर-ए-कोड का लंबा रास्ता शुरू हुआ।

बेशक, एनएसपीके एक स्टार्टअप नहीं है, लेकिन कंपनी के अस्तित्व के पहले वर्षों में ऐसा माहौल था, और वे बहुत दिलचस्प वर्ष थे। मेरा नाम है कोर्न्याकोव दिमित्री, मैं 10 वर्षों से अधिक समय से उच्च उपलब्धता आवश्यकताओं के साथ लिनक्स बुनियादी ढांचे का समर्थन कर रहा हूं। वह जनवरी 2016 में एनएसपीके टीम में शामिल हुए और दुर्भाग्य से, उन्होंने कंपनी के अस्तित्व की शुरुआत नहीं देखी, लेकिन बड़े बदलावों के चरण में आ गए।

सामान्य तौर पर, हम कह सकते हैं कि हमारी टीम कंपनी के लिए 2 उत्पादों की आपूर्ति करती है। पहला है इंफ्रास्ट्रक्चर. मेल को काम करना चाहिए, DNS को काम करना चाहिए, और डोमेन नियंत्रकों को आपको उन सर्वरों में जाने देना चाहिए जो क्रैश नहीं होने चाहिए। कंपनी का आईटी परिदृश्य बहुत बड़ा है! ये व्यवसाय एवं मिशन महत्वपूर्ण प्रणालियाँ हैं, कुछ के लिए उपलब्धता आवश्यकताएँ 99,999 हैं। दूसरा उत्पाद स्वयं सर्वर है, भौतिक और आभासी। मौजूदा लोगों की निगरानी की जानी चाहिए, और नए लोगों को नियमित रूप से कई विभागों के ग्राहकों तक पहुंचाया जाना चाहिए। इस लेख में मैं इस बात पर ध्यान केंद्रित करना चाहता हूं कि हमने सर्वर जीवन चक्र के लिए जिम्मेदार बुनियादी ढांचे को कैसे विकसित किया।

एक यात्रा की शुरूआत

हमारी यात्रा की शुरुआत में, हमारा प्रौद्योगिकी स्टैक इस तरह दिखता था:
ओएस सेंटओएस 7
फ्रीआईपीए डोमेन नियंत्रक
स्वचालन - एन्सिबल(+टॉवर), मोची

यह सब 3 डोमेन में स्थित था, जो कई डेटा केंद्रों में फैला हुआ था। एक डेटा सेंटर में कार्यालय प्रणालियाँ और परीक्षण स्थल हैं, बाकी में PROD है।

एक बिंदु पर सर्वर बनाना इस तरह दिखता था:

VM टेम्पलेट में, CentOS न्यूनतम है और आवश्यक न्यूनतम सही /etc/resolv.conf जैसा है, बाकी Ansible के माध्यम से आता है।

सीएमडीबी - एक्सेल।

यदि सर्वर भौतिक है, तो वर्चुअल मशीन की प्रतिलिपि बनाने के बजाय, कोब्बलर का उपयोग करके उस पर ओएस स्थापित किया गया था - लक्ष्य सर्वर के मैक पते को कोब्बलर कॉन्फ़िगरेशन में जोड़ा जाता है, सर्वर को डीएचसीपी के माध्यम से एक आईपी पता प्राप्त होता है, और फिर ओएस जोड़ दिया गया है।

सबसे पहले हमने कोब्बलर में किसी प्रकार का कॉन्फ़िगरेशन प्रबंधन करने का भी प्रयास किया। लेकिन समय के साथ, इससे अन्य डेटा केंद्रों और वीएम तैयार करने के लिए एन्सिबल कोड दोनों में कॉन्फ़िगरेशन की पोर्टेबिलिटी में समस्याएं आने लगीं।

उस समय, हममें से कई लोगों ने अन्सिबल को बैश का एक सुविधाजनक विस्तार माना और शेल और सेड का उपयोग करने वाले डिज़ाइनों पर कंजूसी नहीं की। कुल मिलाकर बैशिबल। इसने अंततः इस तथ्य को जन्म दिया कि यदि किसी कारण से प्लेबुक सर्वर पर काम नहीं करता है, तो सर्वर को हटाना, प्लेबुक को ठीक करना और इसे फिर से चलाना आसान था। अनिवार्य रूप से स्क्रिप्ट का कोई संस्करण नहीं था, कॉन्फ़िगरेशन की कोई पोर्टेबिलिटी नहीं थी।

उदाहरण के लिए, हम सभी सर्वरों पर कुछ कॉन्फ़िगरेशन बदलना चाहते थे:

हम लॉजिकल सेगमेंट/डेटा सेंटर में मौजूदा सर्वर पर कॉन्फ़िगरेशन बदलते हैं। कभी-कभी एक दिन में नहीं - पहुंच संबंधी आवश्यकताएं और बड़ी संख्या का कानून सभी परिवर्तनों को एक साथ लागू करने की अनुमति नहीं देता है। और कुछ परिवर्तन संभावित रूप से विनाशकारी होते हैं और कुछ को पुनः आरंभ करने की आवश्यकता होती है - सेवाओं से लेकर ओएस तक।
इसे Ansible में ठीक कर रहा हूँ
हम इसे मोची में ठीक करते हैं
प्रत्येक तार्किक खंड/डेटा केंद्र के लिए एन बार दोहराएं

सभी परिवर्तनों को सुचारू रूप से चलाने के लिए, कई कारकों को ध्यान में रखना आवश्यक था, और परिवर्तन लगातार होते रहते हैं।

उत्तरदायी कोड, कॉन्फ़िगरेशन फ़ाइलों को पुनः सक्रिय करना
आंतरिक सर्वोत्तम प्रथाओं को बदलना
घटनाओं/दुर्घटनाओं के विश्लेषण के परिणामों के आधार पर परिवर्तन
आंतरिक और बाह्य दोनों प्रकार के सुरक्षा मानक बदल रहे हैं। उदाहरण के लिए, पीसीआई डीएसएस को हर साल नई आवश्यकताओं के साथ अद्यतन किया जाता है

बुनियादी ढांचे का विकास और यात्रा की शुरुआत

सर्वर/लॉजिकल डोमेन/डेटा केंद्रों की संख्या बढ़ी, और उनके साथ कॉन्फ़िगरेशन में त्रुटियों की संख्या भी बढ़ी। कुछ बिंदु पर, हम तीन दिशाओं में आए जिनमें कॉन्फ़िगरेशन प्रबंधन को विकसित करने की आवश्यकता है:

स्वचालन। दोहराए जाने वाले कार्यों में मानवीय त्रुटि से यथासंभव बचना चाहिए।
पुनरावृत्ति. जब पूर्वानुमान लगाया जा सके तो बुनियादी ढांचे का प्रबंधन करना बहुत आसान होता है। उनकी तैयारी के लिए सर्वर और टूल का कॉन्फ़िगरेशन हर जगह समान होना चाहिए। यह उत्पाद टीमों के लिए भी महत्वपूर्ण है - परीक्षण के बाद, एप्लिकेशन को परीक्षण वातावरण के समान कॉन्फ़िगर किए गए उत्पादन वातावरण में समाप्त होने की गारंटी दी जानी चाहिए।
कॉन्फ़िगरेशन प्रबंधन में परिवर्तन करने की सरलता और पारदर्शिता।

इसमें कुछ उपकरण जोड़ना बाकी है।

हमने GitLab CE को अपने कोड रिपॉजिटरी के रूप में चुना, कम से कम इसके अंतर्निहित CI/CD मॉड्यूल के लिए नहीं।

रहस्यों की तिजोरी - हाशिकोर्प वॉल्ट, सहित। महान एपीआई के लिए.

परीक्षण विन्यास और उत्तरदायी भूमिकाएँ - अणु+टेस्टिनफ़्रा। यदि आप एन्सिबल मिटोजेन से जुड़ते हैं तो परीक्षण बहुत तेजी से आगे बढ़ते हैं। उसी समय, हमने स्वचालित तैनाती के लिए अपना स्वयं का सीएमडीबी और ऑर्केस्ट्रेटर लिखना शुरू कर दिया (कोब्बलर के ऊपर की तस्वीर में), लेकिन यह एक पूरी तरह से अलग कहानी है, जिसे मेरे सहयोगी और इन प्रणालियों के मुख्य डेवलपर भविष्य में बताएंगे।

हमारी पसंद:

अणु + टेस्टिनफ्रा
अन्सिबल + टावर + AWX
सर्वरों की दुनिया + DITNET (स्वयं का विकास)
मोची
गिटलैब + गिटलैब धावक
हाशिकॉर्प वॉल्ट

वैसे, उत्तरदायी भूमिकाओं के बारे में। पहले केवल एक ही था, लेकिन कई रीफैक्टरिंग के बाद उनमें से 17 हो गए। मैं दृढ़ता से मोनोलिथ को निष्क्रिय भूमिकाओं में तोड़ने की सलाह देता हूं, जिसे बाद में अलग से लॉन्च किया जा सकता है; इसके अतिरिक्त, आप टैग जोड़ सकते हैं। हमने भूमिकाओं को कार्यक्षमता के आधार पर विभाजित किया है - नेटवर्क, लॉगिंग, पैकेज, हार्डवेयर, अणु आदि। सामान्य तौर पर, हमने नीचे दी गई रणनीति का पालन किया। मैं इस बात पर ज़ोर नहीं देता कि यही एकमात्र सत्य है, लेकिन इसने हमारे लिए काम किया।

"सुनहरी छवि" से सर्वर की प्रतिलिपि बनाना बुराई है!मुख्य नुकसान यह है कि आप ठीक से नहीं जानते कि छवियां अभी किस स्थिति में हैं, और सभी वर्चुअलाइजेशन फ़ार्मों में सभी छवियों में सभी परिवर्तन आएंगे।
डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइलों का उपयोग कम से कम करें और अन्य विभागों से सहमत हों कि आप मुख्य सिस्टम फ़ाइलों के लिए ज़िम्मेदार हैं, उदाहरण के लिए:
1. /etc/sysctl.conf को खाली छोड़ें, सेटिंग्स केवल /etc/sysctl.d/ में होनी चाहिए। एक फ़ाइल में आपका डिफ़ॉल्ट, दूसरे में एप्लिकेशन के लिए कस्टम।
2. सिस्टमडी इकाइयों को संपादित करने के लिए ओवरराइड फ़ाइलों का उपयोग करें।
सभी कॉन्फ़िगरेशन को टेम्प्लेट करें और उन्हें पूरी तरह से शामिल करें; यदि संभव हो, तो प्लेबुक में कोई सेड या उसका एनालॉग नहीं
कॉन्फ़िगरेशन प्रबंधन सिस्टम कोड को पुनः सक्रिय करना:
1. कार्यों को तार्किक इकाइयों में तोड़ें और मोनोलिथ को भूमिकाओं में फिर से लिखें
2. लिंटर का प्रयोग करें! अन्सिबल-लिंट, यमल-लिंट, आदि
3. अपना दृष्टिकोण बदलें! कोई बैशबल नहीं. व्यवस्था की स्थिति का वर्णन करना आवश्यक है
सभी Ansible भूमिकाओं के लिए आपको अणु में परीक्षण लिखने और दिन में एक बार रिपोर्ट तैयार करने की आवश्यकता है।
हमारे मामले में, परीक्षण तैयार करने के बाद (जिनमें से 100 से अधिक हैं), लगभग 70000 त्रुटियाँ पाई गईं। इसे ठीक करने में कई महीने लग गए.

हमारा कार्यान्वयन

इसलिए, उपयुक्त भूमिकाएँ तैयार थीं, टेम्पलेट की गईं और लिंटर द्वारा जाँच की गईं। और यहां तक कि हर जगह गिट भी उठाए जाते हैं. लेकिन विभिन्न खंडों में विश्वसनीय कोड वितरण का प्रश्न खुला रहा। हमने स्क्रिप्ट के साथ तालमेल बिठाने का निर्णय लिया। ऐसा लगता है:

परिवर्तन आने के बाद, सीआई लॉन्च किया जाता है, एक परीक्षण सर्वर बनाया जाता है, भूमिकाएँ शुरू की जाती हैं, और अणु द्वारा परीक्षण किया जाता है। यदि सब कुछ ठीक है, तो कोड उत्पाद शाखा में चला जाता है। लेकिन हम मशीन में मौजूदा सर्वर पर नया कोड लागू नहीं करते हैं। यह एक प्रकार का स्टॉपर है जो हमारे सिस्टम की उच्च उपलब्धता के लिए आवश्यक है। और जब बुनियादी ढांचा विशाल हो जाता है, तो बड़ी संख्या का कानून लागू होता है - भले ही आप आश्वस्त हों कि परिवर्तन हानिरहित है, इससे गंभीर परिणाम हो सकते हैं।

सर्वर बनाने के भी कई विकल्प हैं। हमने अंततः कस्टम पायथन स्क्रिप्ट का चयन किया। और सीआई उत्तरयोग्य के लिए:

- 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 उत्तरदायी भूमिकाएँ। प्रत्येक भूमिका को एक अलग तार्किक कार्य (लॉगिंग, ऑडिटिंग, उपयोगकर्ता प्राधिकरण, निगरानी, आदि) को हल करने के लिए डिज़ाइन किया गया है।
भूमिका परीक्षण. अणु + टेस्टइन्फ्रा।
स्वयं का विकास: सीएमडीबी + ऑर्केस्ट्रेटर।
सर्वर निर्माण का समय ~30 मिनट है, स्वचालित और व्यावहारिक रूप से कार्य कतार से स्वतंत्र।
सभी खंडों में बुनियादी ढांचे की समान स्थिति/नामकरण - प्लेबुक, रिपॉजिटरी, वर्चुअलाइजेशन तत्व।
मानक के साथ विसंगतियों पर रिपोर्ट तैयार करने के साथ सर्वर स्थिति की दैनिक जांच।

मुझे उम्मीद है कि मेरी कहानी उन लोगों के लिए उपयोगी होगी जो अपनी यात्रा की शुरुआत में हैं। आप किस ऑटोमेशन स्टैक का उपयोग करते हैं?

स्रोत: www.habr.com