🥇 "स्टार्टअप" देखि दर्जनौं डेटा केन्द्रहरूमा हजारौं सर्भरहरूमा। हामीले लिनक्स पूर्वाधारको विकासलाई कसरी पछ्यायौं

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

निस्सन्देह, NSPK स्टार्टअप होइन, तर यस्तो वातावरण कम्पनीमा यसको अस्तित्वको पहिलो वर्षमा शासन गर्यो, र ती धेरै रोचक वर्षहरू थिए। मेरो नाम Kornyakov दिमित्री, मैले 10 वर्ष भन्दा बढीको लागि उच्च उपलब्धता आवश्यकताहरूको साथ लिनक्स पूर्वाधारलाई समर्थन गर्दै आएको छु। उहाँ जनवरी 2016 मा NSPK टोलीमा सामेल हुनुभयो र दुर्भाग्यवश, कम्पनीको अस्तित्वको शुरुवात देखिएन, तर ठूलो परिवर्तनको चरणमा आयो।

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

बाटोको सुरुवात

हाम्रो यात्राको सुरुमा, हाम्रो टेक्नोलोजी स्ट्याक यस्तो देखिन्थ्यो:
OS CentOS 7
FreeIPA डोमेन नियन्त्रकहरू
स्वचालन - उत्तरदायी (+ टावर), मोची

यो सबै 3 डोमेनहरूमा अवस्थित थियो, धेरै डाटा केन्द्रहरूमा फैलिएको थियो। एउटा डाटा सेन्टरमा अफिस प्रणाली र परीक्षण साइटहरू छन्, बाँकीमा त्यहाँ PROD छ।

एक बिन्दुमा सर्भरहरू सिर्जना गर्दा यस्तो देखिन्थ्यो:

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

CMDB - एक्सेल।

यदि सर्भर भौतिक छ भने, भर्चुअल मेसिनको प्रतिलिपि गर्नुको सट्टा, Cobbler प्रयोग गरेर OS स्थापना गरिएको थियो - लक्ष्य सर्भरको MAC ठेगानाहरू Cobbler कन्फिगरेसनमा थपिन्छन्, सर्भरले DHCP मार्फत IP ठेगाना प्राप्त गर्दछ, र त्यसपछि OS। थपिएको छ।

सुरुमा हामीले Cobbler मा केहि प्रकारको कन्फिगरेसन व्यवस्थापन गर्ने प्रयास गर्यौं। तर समय बित्दै जाँदा, यसले कन्फिगरेसनको पोर्टेबिलिटीमा अन्य डाटा सेन्टरहरू र VMs तयार गर्नका लागि उत्तरदायी कोड दुवैमा समस्या ल्याउन थाल्यो।

त्यस समयमा, हामी मध्ये धेरैले Ansible लाई Bash को सुविधाजनक विस्तारको रूपमा बुझ्यौं र शेल र sed प्रयोग गरी डिजाइनहरूमा स्किम गरेनौं। समग्रमा Bashsible। यसले अन्ततः यस तथ्यलाई निम्त्यायो कि यदि प्लेबुकले कुनै कारणले सर्भरमा काम गरेन भने, सर्भर मेटाउन, प्लेबुक ठीक गर्न र यसलाई फेरि चलाउन सजिलो थियो। त्यहाँ अनिवार्य रूपमा लिपिहरूको कुनै संस्करण थिएन, कन्फिगरेसनहरूको पोर्टेबिलिटी थिएन।

उदाहरणका लागि, हामी सबै सर्भरहरूमा केही कन्फिगरेसन परिवर्तन गर्न चाहन्छौं:

हामी तार्किक खण्ड/डेटा केन्द्रमा अवस्थित सर्भरहरूमा कन्फिगरेसन परिवर्तन गर्छौं। कहिलेकाहीँ एक दिनमा होइन - पहुँच आवश्यकताहरू र ठूलो संख्याको कानूनले सबै परिवर्तनहरू एकैचोटि लागू गर्न अनुमति दिँदैन। र केहि परिवर्तनहरू सम्भावित विनाशकारी छन् र केहि पुन: सुरु गर्न आवश्यक छ - सेवाहरू देखि OS मा।
जवाफमा यसलाई ठीक गर्दै
हामी यसलाई Cobbler मा ठीक गर्छौं
प्रत्येक तार्किक खण्ड/डेटा केन्द्रको लागि N पटक दोहोर्याउनुहोस्

सबै परिवर्तनहरू सहज रूपमा जानको लागि, धेरै कारकहरूलाई ध्यानमा राख्न आवश्यक थियो, र परिवर्तनहरू निरन्तर हुन्छन्।

रिफ्याक्टरिङ उत्तरदायी कोड, कन्फिगरेसन फाइलहरू
आन्तरिक उत्कृष्ट अभ्यासहरू परिवर्तन गर्दै
घटना/दुर्घटनाको विश्लेषणको नतिजामा आधारित परिवर्तनहरू
आन्तरिक र बाह्य दुवै सुरक्षा मापदण्डहरू परिवर्तन गर्दै। उदाहरणका लागि, PCI DSS हरेक वर्ष नयाँ आवश्यकताहरूसँग अद्यावधिक गरिन्छ

पूर्वाधार विकास र यात्राको सुरुवात

सर्भर/तार्किक डोमेन/डेटा केन्द्रहरूको संख्या बढ्यो, र तिनीहरूसँग कन्फिगरेसनहरूमा त्रुटिहरूको संख्या बढ्यो। केहि बिन्दुमा, हामी कन्फिगरेसन व्यवस्थापन विकास गर्न आवश्यक तीन दिशाहरूमा आएका छौं:

स्वचालन। दोहोरिने कार्यहरूमा मानव त्रुटिलाई सकेसम्म बेवास्ता गर्नुपर्छ।
पुनरावृत्ति। पूर्वाधार व्यवस्थापन गर्न धेरै सजिलो छ जब यो अनुमान गर्न सकिन्छ। तिनीहरूको तयारीको लागि सर्भर र उपकरणहरूको कन्फिगरेसन जताततै समान हुनुपर्छ। यो उत्पादन टोलीहरूको लागि पनि महत्त्वपूर्ण छ - परीक्षण पछि, अनुप्रयोग परीक्षण वातावरण जस्तै कन्फिगर गरिएको उत्पादन वातावरणमा समाप्त हुने ग्यारेन्टी हुनुपर्छ।
कन्फिगरेसन व्यवस्थापनमा परिवर्तन गर्ने सरलता र पारदर्शिता।

यो उपकरण को एक जोडी थप्न बाँकी छ।

हामीले GitLab CE लाई हाम्रो कोड भण्डारको रूपमा रोज्यौं, कम्तिमा यसको निर्मित CI/CD मोड्युलहरूको लागि होइन।

सेक्रेट्स को भल्ट - Hashicorp Vault, सहित। महान API को लागी।

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

हाम्रो छनौट:

अणु + टेस्टिनफ्रा
उत्तरदायी + टावर + AWX
सर्भरहरूको संसार + DITNET (आफ्नो विकास)
मोची
Gitlab + GitLab धावक
हाशिकोर्प भल्ट

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

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

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

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

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

त्यहाँ सर्भरहरू सिर्जना गर्नका लागि धेरै विकल्पहरू छन्। हामीले अनुकूलन पाइथन स्क्रिप्टहरू छनौट गर्न समाप्त गर्यौं। र CI उत्तरदायी को लागी:

- 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 + अर्केस्ट्रेटर।
सर्भर निर्माण समय ~30 मिनेट हो, स्वचालित र व्यावहारिक रूपमा कार्य लामबाट स्वतन्त्र।
सबै खण्डहरूमा पूर्वाधारको समान अवस्था/नामकरण - प्लेबुकहरू, भण्डारहरू, भर्चुअलाइजेसन तत्वहरू।
सर्भर स्थितिको दैनिक जाँच मानकसँग भिन्नताहरूमा रिपोर्टहरूको उत्पादनको साथ।

मलाई आशा छ कि मेरो कथा आफ्नो यात्राको सुरुमा भएकाहरूलाई उपयोगी हुनेछ। तपाइँ कुन स्वचालन स्ट्याक प्रयोग गर्नुहुन्छ?

स्रोत: www.habr.com