"شروعاتي" کان وٺي هزارين سرورن ۾ درجن جي ڊيٽا سينٽرن ۾. اسان ڪيئن لينڪس انفراسٽرڪچر جي ترقي جو تعاقب ڪيو

جيڪڏهن توهان جو IT انفراسٽرڪچر تمام جلدي وڌي ٿو، توهان کي جلدي يا بعد ۾ هڪ انتخاب سان منهن ڏيڻو پوندو: ان جي حمايت ڪرڻ يا خودڪار شروع ڪرڻ لاء انساني وسيلن کي لڪير ۾ وڌايو. ڪجهه نقطي تائين، اسان پهرين پيراڊائم ۾ رهندا هئاسين، ۽ پوء انفراسٽرڪچر-جي-ڪوڊ تائين ڊگهو رستو شروع ٿيو.

يقينا، NSPK هڪ شروعاتي نه آهي، پر اهڙي ماحول ڪمپنيء ۾ پنهنجي وجود جي پهرين سالن ۾ راڄ ڪيو، ۽ اهي تمام دلچسپ سال هئا. منهنجو نالو آهي Kornyakov دمتري، مان 10 سالن کان وڌيڪ دستيابي گهرجن سان لينڪس انفراسٽرڪچر جي مدد ڪري رهيو آهيان. هن جنوري 2016 ۾ NSPK ٽيم ۾ شامل ٿيو ۽ بدقسمتي سان، ڪمپني جي وجود جي شروعات کي نه ڏٺو، پر وڏي تبديلين جي مرحلي ۾ آيو.

عام طور تي، اسان اهو چئي سگهون ٿا ته اسان جي ٽيم ڪمپني لاء 2 پراڊڪٽ فراهم ڪري ٿي. پهرين بنيادي ڍانچي آهي. ميل کي ڪم ڪرڻ گهرجي، DNS ڪم ڪرڻ گهرجي، ۽ ڊومين سنڀاليندڙن کي توهان کي سرور ۾ وڃڻ گهرجي جيڪي حادثي نه ٿيڻ گهرجن. ڪمپني جي آئي ٽي منظوري تمام وڏي آهي! اهي ڪاروبار ۽ مشن نازڪ نظام آهن، ڪجهه لاء دستيابي گهربل آهن 99,999. ٻيو پراڊڪٽ خود سرور آهي، جسماني ۽ مجازي. موجوده ماڻهن کي مانيٽر ڪرڻ جي ضرورت آهي، ۽ نوان کي باقاعده طور تي ڪيترن ئي شعبن کان گراهڪن تائين پهچايو وڃي. هن آرٽيڪل ۾ آئون انهي ڳالهه تي ڌيان ڏيڻ چاهيان ٿو ته اسان بنيادي ڍانچي کي ڪيئن ترقي ڪئي جيڪا سرور جي زندگي جي چڪر لاء ذميوار آهي.

رستي جو آغاز

اسان جي سفر جي شروعات ۾، اسان جي ٽيڪنالاجي اسٽيڪ هن طرح نظر آئي:
او ايس CentOS 7
FreeIPA ڊومين ڪنٽرولرز
خودڪار - جوابي (+ ٽاور)، موچي

هي سڀ 3 ڊومينز ۾ واقع هو، ڪيترن ئي ڊيٽا سينٽرن ۾ پکڙيل آهي. هڪ ڊيٽا سينٽر ۾ آفيس سسٽم ۽ ٽيسٽ سائيٽون آهن، باقي اتي PROD آهي.

هڪ نقطي تي سرور ٺاهڻ هن طرح ڏٺو:

VM ٽيمپليٽ ۾، CentOS گهٽ ۾ گهٽ آهي ۽ گهربل گهٽ ۾ گهٽ صحيح آهي /etc/resolv.conf، باقي اچي ٿو جوابي ذريعي.

CMDB - Excel.

جيڪڏهن سرور جسماني آهي، ته پوءِ ورچوئل مشين کي نقل ڪرڻ بدران، او ايس ان تي نصب ڪيو ويو Cobbler استعمال ڪندي - ٽارگيٽ سرور جا MAC ايڊريس Cobbler config ۾ شامل ڪيا ويا آهن، سرور هڪ IP پتو DHCP ذريعي وصول ڪري ٿو، ۽ پوءِ او ايس شامل ڪيو ويو آهي.

پهرين ته اسان ڪوشش ڪئي ته ڪوبلر ۾ ڪجهه قسم جي ترتيب واري انتظام کي. پر وقت سان گڏ، هي ٻئي ڊيٽا سينٽرن ۽ VMs تيار ڪرڻ لاءِ جوابي ڪوڊ تائين ترتيبن جي پورائيبلٽي سان مسئلا آڻڻ شروع ڪيو.

ان وقت، اسان مان گھڻن جوابن کي بش جي آسان توسيع جي طور تي سمجھيو ۽ شيل ۽ سيڊ استعمال ڪندي ڊزائينز تي ڌيان نه ڏنو. مجموعي طور تي Bashsible. اهو آخرڪار هن حقيقت ڏانهن وڌيو ته جيڪڏهن ڪنهن سبب لاءِ پلي بڪ سرور تي ڪم نه ڪيو، اهو سرور کي حذف ڪرڻ، پلے بڪ کي درست ڪرڻ ۽ ان کي ٻيهر هلائڻ آسان هو. اتي لازمي طور تي اسڪرپٽ جو ڪوبه نسخو نه هو، ترتيبن جي پورائيبلٽي نه هئي.

مثال طور، اسان سڀني سرورن تي ڪجهه ترتيب تبديل ڪرڻ چاهيون ٿا:

1. اسان موجوده سرورز تي ٺاھ جوڙ تبديل ڪريون ٿا منطقي ڀاڱي/ڊيٽا سينٽر ۾. ڪڏهن ڪڏهن هڪ ڏينهن ۾ نه - رسائي جي گهرج ۽ وڏي انگ جو قانون سڀني تبديلين کي هڪ ئي وقت ۾ لاڳو ٿيڻ جي اجازت ناهي. ۽ ڪجھ تبديليون امڪاني طور تي تباھي ڪندڙ آھن ۽ ڪجھ کي ٻيهر شروع ڪرڻ جي ضرورت آھي - خدمتن کان وٺي او ايس تائين.
2. جواب ۾ ان کي درست ڪرڻ
3. اسان ان کي Cobbler ۾ ٺيڪ ڪريو
4. هر منطقي حصي/ڊيٽا سينٽر لاءِ N ڀيرا ورجايو

سڀني تبديلين کي آسانيء سان وڃڻ لاء، اهو ضروري آهي ته ڪيترن ئي عنصر کي ڌيان ڏيڻ گهرجي، ۽ تبديليون مسلسل ٿينديون آهن.

• جواب ڏيڻ وارو ڪوڊ، ترتيب ڏيڻ واريون فائلون
• اندروني بهترين طريقن کي تبديل ڪرڻ
• تبديليون واقعن/حادثن جي تجزيو جي نتيجن جي بنياد تي
• سيڪيورٽي معيار کي تبديل ڪرڻ، اندروني ۽ بيروني ٻنهي. مثال طور، PCI DSS هر سال نئين گهرجن سان اپڊيٽ ڪيو ويندو آهي

انفراسٹرڪچر جي ترقي ۽ سفر جي شروعات

سرورز / منطقي ڊومينز / ڊيٽا سينٽرن جو تعداد وڌايو، ۽ انھن سان گڏ ترتيبن ۾ غلطين جو تعداد. ڪجهه نقطي تي، اسان ٽن طرفن ڏانهن آياسين جنهن ۾ ترتيب جي انتظام کي ترقي ڪرڻ جي ضرورت آهي:

1. آٽوميشن. بار بار ٿيندڙ عملن ۾ انساني غلطي کان جيترو ٿي سگهي پاسو ڪيو وڃي.
2. ورجائي قابليت. انفراسٹرڪچر کي منظم ڪرڻ تمام آسان آهي جڏهن اهو پيش گوئي آهي. انهن جي تياري لاءِ سرورز ۽ اوزارن جي ترتيب هر هنڌ هڪجهڙي هجڻ گهرجي. اهو پراڊڪٽ ٽيمن لاءِ پڻ اهم آهي - جاچ کان پوءِ، ايپليڪيشن کي يقيني بڻائڻ گهرجي ته پيداوار واري ماحول ۾ ختم ٿيڻ جي لاءِ ساڳي طرح ترتيب ڏنل ٽيسٽ ماحول سان.
3. سادگي ۽ شفافيت جي جوڙجڪ جي انتظام ۾ تبديليون.

اهو ڪجهه اوزار شامل ڪرڻ لاء رهي ٿو.

اسان چونڊيو GitLab CE اسان جي ڪوڊ مخزن جي طور تي، گهٽ ۾ گهٽ ان جي تعمير ٿيل CI/CD ماڊلز لاءِ.

رازن جو خزانو - Hashicorp Vault، incl. عظيم API لاءِ.

جانچ جي ترتيب ۽ جوابي ڪردار - ماليڪيول + ٽيسٽنفرا. ٽيسٽ تمام تيز ٿين ٿا جيڪڏھن توھان ڳنڍي سگھوٿا جوابي مائيٽوجن. ساڳي ئي وقت، اسان پاڻمرادو ترتيب ڏيڻ لاءِ پنهنجو سي ايم ڊي بي ۽ آرڪيسٽرٽر لکڻ شروع ڪيو (مٿي ڏنل تصوير ۾ Cobbler)، پر اهو هڪ مڪمل طور تي مختلف ڪهاڻي آهي، جيڪو منهنجو ساٿي ۽ انهن سسٽم جو مکيه ڊولپر مستقبل ۾ ٻڌائيندو.

اسان جو انتخاب:

ماليڪيول + ٽيسٽنفرا
جوابي + ٽاور + AWX
سرورز جي دنيا + DITNET (پنهنجي ترقي)
موچي
Gitlab + GitLab رنر
Hashicorp Vault

رستي ۾، جوابي ڪردار بابت. شروعات ۾ صرف هڪ هو، پر ڪيترن ئي ريفريڪٽرنگ کان پوء انهن مان 17 هئا، مان سختي سان سفارش ڪريان ٿو ته مونولٿ کي idempotent ڪردارن ۾ ٽوڙڻ، جيڪو پوء الڳ الڳ شروع ڪري سگهجي ٿو؛ اضافي طور تي، توهان ٽيگ شامل ڪري سگهو ٿا. اسان ڪردارن کي ڪارڪردگيءَ سان ورهايو - نيٽ ورڪ، لاگنگ، پيڪيجز، هارڊويئر، ماليڪيول وغيره. عام طور تي، اسان هيٺ ڏنل حڪمت عملي تي عمل ڪيو. مان اصرار نه ٿو ڪريان ته اهو واحد سچ آهي، پر اهو اسان لاء ڪم ڪيو.

• سرورز کي ”سونهري تصوير“ مان نقل ڪرڻ برائي آهي!مکيه نقصان اهو آهي ته توهان کي خبر ناهي ته تصويرون ڪهڙي حالت ۾ آهن، ۽ اهي سڀئي تبديليون سڀني ورچوئلائيزيشن فارمن ۾ سڀني تصويرن ۾ اينديون.
• گھٽ ۾ گھٽ ڊفالٽ ڪنفيگريشن فائلون استعمال ڪريو ۽ ٻين شعبن سان متفق ٿيو ته توھان مکيه سسٽم فائلن جا ذميوار آھيومثال طور
  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 سرور قائم ڪرڻ لاءِ جوابي ڪردار. هر هڪ ڪردار هڪ الڳ منطقي ڪم (لاگنگ، آڊيٽنگ، صارف اختيار، نگراني، وغيره) کي حل ڪرڻ لاء ٺهيل آهي.
• ڪردار جي جاچ. Molecule + TestInfra.
• ذاتي ترقي: CMDB + آرڪيسٽرٽر.
• سرور ٺاهڻ جو وقت ~ 30 منٽ آهي، خودڪار ۽ عملي طور تي ڪم جي قطار کان آزاد.
• ساڳئي رياست / سڀني حصن ۾ زيربناء جو نالو - راند ڪتاب، مخزن، ورچوئلائيزيشن عناصر.
• معيار سان اختلافن تي رپورٽن جي پيداوار سان سرور جي صورتحال جي روزاني چيڪ.

مون کي اميد آهي ته منهنجي ڪهاڻي انهن لاء مفيد ثابت ٿيندي جيڪي پنهنجي سفر جي شروعات ۾ آهن. توهان ڪهڙي آٽوميشن اسٽيڪ استعمال ڪندا آهيو؟

جو ذريعو: www.habr.com