🥇 "स्टार्टअप" पासून डझनभर डेटा केंद्रांमधील हजारो सर्व्हरपर्यंत. लिनक्स इन्फ्रास्ट्रक्चरच्या वाढीचा आम्ही कसा पाठलाग केला

जर तुमची आयटी पायाभूत सुविधा खूप लवकर वाढली, तर तुम्हाला लवकरच किंवा नंतर एका पर्यायाचा सामना करावा लागेल: त्याला समर्थन देण्यासाठी मानवी संसाधने वाढवा किंवा ऑटोमेशन सुरू करा. काही क्षणापर्यंत, आम्ही पहिल्या पॅराडाइममध्ये राहिलो, आणि नंतर इन्फ्रास्ट्रक्चर-एज-कोडचा लांब मार्ग सुरू झाला.

अर्थात, एनएसपीके ही स्टार्टअप नाही, परंतु कंपनीच्या अस्तित्वाच्या पहिल्या वर्षांत असे वातावरण राज्य केले गेले आणि ती वर्षे खूप मनोरंजक होती. माझं नावं आहे कोर्न्याकोव्ह दिमित्री, मी 10 वर्षांहून अधिक काळ उच्च उपलब्धता आवश्यकतांसह Linux पायाभूत सुविधांना समर्थन देत आहे. तो जानेवारी 2016 मध्ये NSPK संघात सामील झाला आणि दुर्दैवाने, कंपनीच्या अस्तित्वाची सुरुवातच दिसली नाही, परंतु मोठ्या बदलांच्या टप्प्यावर तो आला.

सर्वसाधारणपणे, आम्ही असे म्हणू शकतो की आमचा कार्यसंघ कंपनीसाठी 2 उत्पादने पुरवतो. पहिली म्हणजे पायाभूत सुविधा. मेलने कार्य केले पाहिजे, DNS ने कार्य केले पाहिजे आणि डोमेन नियंत्रकांनी तुम्हाला अशा सर्व्हरमध्ये जाऊ द्यावे जे क्रॅश होऊ नयेत. कंपनीचे आयटी लँडस्केप प्रचंड आहे! या व्यवसाय आणि मिशन क्रिटिकल सिस्टम आहेत, काहींसाठी उपलब्धता आवश्यकता 99,999 आहेत. दुसरे उत्पादन स्वतः सर्व्हर आहे, भौतिक आणि आभासी. विद्यमान असलेल्यांचे निरीक्षण करणे आवश्यक आहे आणि नवीन अनेक विभागांमधील ग्राहकांना नियमितपणे वितरित केले जाणे आवश्यक आहे. या लेखात मी सर्व्हर लाइफ सायकलसाठी जबाबदार असलेल्या पायाभूत सुविधा कशा विकसित केल्या यावर मी लक्ष केंद्रित करू इच्छितो.

वाटेची सुरुवात

आमच्या प्रवासाच्या सुरुवातीला, आमचा तंत्रज्ञान स्टॅक यासारखा दिसत होता:
OS CentOS 7
फ्रीआयपीए डोमेन कंट्रोलर्स
ऑटोमेशन - उत्तरदायी (+टॉवर), मोची

हे सर्व 3 डोमेनमध्ये स्थित होते, अनेक डेटा सेंटरमध्ये पसरलेले होते. एका डेटा सेंटरमध्ये ऑफिस सिस्टम आणि चाचणी साइट्स आहेत, बाकीच्या भागात PROD आहे.

एका टप्प्यावर सर्व्हर तयार करणे असे दिसले:

VM टेम्पलेटमध्ये, CentOS किमान आहे आणि आवश्यक किमान योग्य /etc/resolv.conf प्रमाणे आहे, बाकीचे Ansible द्वारे येते.

CMDB - एक्सेल.

जर सर्व्हर भौतिक असेल, तर व्हर्च्युअल मशीन कॉपी करण्याऐवजी, त्यावर कोब्बलर वापरून ओएस स्थापित केले गेले होते - लक्ष्य सर्व्हरचे MAC पत्ते कोब्बलर कॉन्फिगरेशनमध्ये जोडले जातात, सर्व्हरला DHCP द्वारे IP पत्ता प्राप्त होतो आणि नंतर OS. जोडले जाते.

सुरुवातीला आम्ही कोब्बलरमध्ये काही प्रकारचे कॉन्फिगरेशन व्यवस्थापन करण्याचा प्रयत्न केला. परंतु कालांतराने, यामुळे इतर डेटा सेंटर्स आणि VM तयार करण्यासाठी उत्तरदायी कोड या दोन्ही कॉन्फिगरेशनच्या पोर्टेबिलिटीमध्ये समस्या येऊ लागल्या.

त्या वेळी, आपल्यापैकी बर्‍याच जणांना Ansible ला Bash चा सोयीस्कर विस्तार समजला आणि शेल आणि sed वापरून डिझाईन्समध्ये कसूर केली नाही. एकूणच बाशसिबल. यामुळे शेवटी असे घडले की जर काही कारणास्तव प्लेबुक सर्व्हरवर कार्य करत नसेल तर सर्व्हर हटवणे, प्लेबुक दुरुस्त करणे आणि ते पुन्हा चालवणे सोपे होते. मुळात स्क्रिप्ट्सची आवृत्ती नव्हती, कॉन्फिगरेशनची पोर्टेबिलिटी नव्हती.

उदाहरणार्थ, आम्हाला सर्व सर्व्हरवर काही कॉन्फिगरेशन बदलायचे होते:

आम्ही लॉजिकल सेगमेंट/डेटा सेंटरमधील विद्यमान सर्व्हरवरील कॉन्फिगरेशन बदलतो. कधीकधी एका दिवसात नाही - प्रवेशयोग्यता आवश्यकता आणि मोठ्या संख्येचा कायदा सर्व बदल एकाच वेळी लागू करण्याची परवानगी देत नाही. आणि काही बदल संभाव्यतः विध्वंसक आहेत आणि काहीतरी रीस्टार्ट करणे आवश्यक आहे - सेवांपासून ते OS पर्यंत.
Ansible मध्ये त्याचे निराकरण करणे
आम्ही ते कोब्बलरमध्ये निश्चित करतो
प्रत्येक लॉजिकल सेगमेंट/डेटा सेंटरसाठी N वेळा पुन्हा करा

सर्व बदल सहजतेने होण्यासाठी, अनेक घटक विचारात घेणे आवश्यक होते आणि बदल सतत होत असतात.

रिफॅक्टरिंग उत्तरदायी कोड, कॉन्फिगरेशन फाइल्स
अंतर्गत सर्वोत्तम पद्धती बदलणे
घटना/अपघातांच्या विश्लेषणाच्या परिणामांवर आधारित बदल
अंतर्गत आणि बाह्य दोन्ही सुरक्षा मानके बदलणे. उदाहरणार्थ, PCI DSS दरवर्षी नवीन आवश्यकतांसह अद्यतनित केले जाते

पायाभूत सुविधांची वाढ आणि प्रवासाची सुरुवात

सर्व्हर/लॉजिकल डोमेन/डेटा सेंटर्सची संख्या वाढली आणि त्यांच्यासोबत कॉन्फिगरेशनमधील त्रुटींची संख्या वाढली. काही ठिकाणी, आम्ही तीन दिशानिर्देशांवर आलो ज्यामध्ये कॉन्फिगरेशन व्यवस्थापन विकसित करणे आवश्यक आहे:

ऑटोमेशन. पुनरावृत्ती केलेल्या ऑपरेशन्समध्ये मानवी त्रुटी शक्य तितक्या टाळल्या पाहिजेत.
पुनरावृत्तीक्षमता. जेव्हा अंदाज बांधता येतो तेव्हा पायाभूत सुविधा व्यवस्थापित करणे खूप सोपे असते. त्यांच्या तयारीसाठी सर्व्हर आणि साधनांचे कॉन्फिगरेशन सर्वत्र समान असावे. हे उत्पादन संघांसाठी देखील महत्त्वाचे आहे - चाचणी केल्यानंतर, अनुप्रयोग चाचणी वातावरणाप्रमाणेच कॉन्फिगर केलेल्या उत्पादन वातावरणात समाप्त होण्याची हमी देणे आवश्यक आहे.
कॉन्फिगरेशन व्यवस्थापनामध्ये बदल करण्याची साधेपणा आणि पारदर्शकता.

काही साधने जोडणे बाकी आहे.

आम्ही आमच्या कोड रेपॉजिटरी म्हणून GitLab CE निवडले, किमान त्याच्या अंगभूत CI/CD मॉड्यूल्ससाठी नाही.

व्हॉल्ट ऑफ सिक्रेट्स - हॅशिकॉर्प वॉल्ट, समावेश. महान API साठी.

चाचणी कॉन्फिगरेशन आणि उत्तरदायी भूमिका - रेणू + टेस्टिनफ्रा. तुम्ही उत्तरदायी माइटोजेनशी कनेक्ट केल्यास चाचण्या अधिक जलद होतात. त्याच वेळी, आम्ही आमचे स्वतःचे सीएमडीबी आणि ऑर्केस्ट्रेटर स्वयंचलित उपयोजन (कोब्बलर वरील चित्रात) लिहायला सुरुवात केली, परंतु ही एक पूर्णपणे वेगळी कथा आहे, जी माझे सहकारी आणि या प्रणालींचे मुख्य विकसक भविष्यात सांगतील.

आमची निवड:

रेणू + टेस्टिनफ्रा
उत्तरदायी + टॉवर + AWX
सर्व्हरचे जग + DITNET (स्वतःचा विकास)
मोची
Gitlab + GitLab धावपटू
हॅशिकॉर्प व्हॉल्ट

तसे, उत्तरदायी भूमिकांबद्दल. सुरुवातीला फक्त एकच होता, परंतु अनेक रिफॅक्टरिंगनंतर त्यापैकी 17 होते. मी जोरदारपणे मोनोलिथला इडम्पोटेंट भूमिकांमध्ये मोडण्याची शिफारस करतो, जे नंतर स्वतंत्रपणे लॉन्च केले जाऊ शकतात; याव्यतिरिक्त, आपण टॅग जोडू शकता. आम्ही कार्यक्षमतेनुसार भूमिकांची विभागणी केली - नेटवर्क, लॉगिंग, पॅकेजेस, हार्डवेअर, रेणू इ. सर्वसाधारणपणे, आम्ही खालील धोरणाचे अनुसरण केले. मी असा आग्रह करत नाही की हे एकमेव सत्य आहे, परंतु ते आमच्यासाठी कार्य करते.

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

आमची अंमलबजावणी

तर, उत्तरदायी भूमिका तयार, टेम्प्लेट केलेल्या आणि लिंटरद्वारे तपासल्या गेल्या. आणि सर्वत्र गिट्स देखील उभे केले जातात. परंतु विविध विभागांना विश्वसनीय कोड वितरणाचा प्रश्न खुला राहिला. आम्ही स्क्रिप्ट्ससह सिंक्रोनाइझ करण्याचा निर्णय घेतला. असे दिसते:

बदल आल्यानंतर, 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 उत्तरदायी भूमिका. प्रत्येक भूमिका स्वतंत्र तार्किक कार्य (लॉगिंग, ऑडिटिंग, वापरकर्ता अधिकृतता, देखरेख इ.) सोडवण्यासाठी डिझाइन केलेली आहे.
भूमिका चाचणी. रेणू + TestInfra.
स्वतःचा विकास: CMDB + ऑर्केस्ट्रेटर.
सर्व्हर तयार करण्याची वेळ ~30 मिनिटे आहे, स्वयंचलित आणि कार्य रांगेपासून व्यावहारिकदृष्ट्या स्वतंत्र.
सर्व विभागांमध्ये पायाभूत सुविधांची समान स्थिती/नामकरण - प्लेबुक, रेपॉजिटरीज, वर्च्युअलायझेशन घटक.
मानकांसह विसंगतींच्या अहवालांच्या निर्मितीसह सर्व्हर स्थितीची दैनिक तपासणी.

मला आशा आहे की माझी कथा त्यांच्या प्रवासाच्या सुरुवातीला असलेल्यांना उपयोगी पडेल. तुम्ही कोणता ऑटोमेशन स्टॅक वापरता?

स्त्रोत: www.habr.com