ایک "اسٹارٹ اپ" سے لے کر ایک درجن ڈیٹا سینٹرز میں ہزاروں سرورز تک۔ کس طرح ہم نے لینکس کے بنیادی ڈھانچے کی ترقی کا پیچھا کیا۔

اگر آپ کا آئی ٹی انفراسٹرکچر بہت تیزی سے بڑھتا ہے، تو آپ کو جلد یا بدیر ایک انتخاب کا سامنا کرنا پڑے گا: اس کی حمایت کرنے یا آٹومیشن شروع کرنے کے لیے انسانی وسائل میں خطی طور پر اضافہ کریں۔ کچھ وقت تک، ہم پہلے پیراڈائم میں رہتے تھے، اور پھر انفراسٹرکچر کے طور پر کوڈ کا طویل راستہ شروع ہوا۔

بلاشبہ، NSPK کوئی سٹارٹ اپ نہیں ہے، لیکن کمپنی میں اس کے وجود کے پہلے سالوں میں اس طرح کا ماحول رہا، اور وہ سال بہت دلچسپ تھے۔ میرا نام ہے کورنیاکوف دمتریمیں 10 سالوں سے اعلیٰ دستیابی کے تقاضوں کے ساتھ لینکس کے بنیادی ڈھانچے کی حمایت کر رہا ہوں۔ اس نے جنوری 2016 میں NSPK ٹیم میں شمولیت اختیار کی اور بدقسمتی سے، کمپنی کے وجود کا آغاز ہی نہیں دیکھا، لیکن بڑی تبدیلیوں کے مرحلے پر آیا۔

عام طور پر، ہم کہہ سکتے ہیں کہ ہماری ٹیم کمپنی کے لیے 2 مصنوعات فراہم کرتی ہے۔ پہلا بنیادی ڈھانچہ ہے۔ میل کو کام کرنا چاہیے، DNS کو کام کرنا چاہیے، اور ڈومین کنٹرولرز آپ کو ایسے سرورز میں جانے دیں جو کریش نہ ہوں۔ کمپنی کا آئی ٹی زمین کی تزئین بہت بڑا ہے! یہ کاروباری اور مشن کے اہم نظام ہیں، کچھ کے لیے دستیابی کی ضروریات 99,999 ہیں۔ دوسری مصنوعات خود سرورز ہیں، جسمانی اور ورچوئل۔ موجودہ پر نظر رکھنے کی ضرورت ہے، اور نئے کو باقاعدگی سے بہت سے محکموں کے صارفین تک پہنچایا جانا چاہیے۔ اس مضمون میں میں اس بات پر توجہ مرکوز کرنا چاہتا ہوں کہ ہم نے کس طرح بنیادی ڈھانچہ تیار کیا جو سرور لائف سائیکل کے لیے ذمہ دار ہے۔

شروع سفر کا

ہمارے سفر کے آغاز میں، ہماری ٹیکنالوجی اسٹیک اس طرح نظر آتی تھی:
OS CentOS 7
فری آئی پی اے ڈومین کنٹرولرز
آٹومیشن - جوابدہ (+ٹاور)، موچی

یہ سب 3 ڈومینز میں واقع تھا، جو کئی ڈیٹا سینٹرز میں پھیلا ہوا تھا۔ ایک ڈیٹا سینٹر میں آفس سسٹم اور ٹیسٹ سائٹس ہیں، باقی میں PROD ہے۔

ایک موقع پر سرور بنانا اس طرح نظر آیا:

VM ٹیمپلیٹ میں، CentOS کم سے کم ہے اور مطلوبہ کم از کم درست /etc/resolv.conf کی طرح ہے، باقی Ansible کے ذریعے آتا ہے۔

CMDB - ایکسل۔

اگر سرور فزیکل ہے، تو ورچوئل مشین کو کاپی کرنے کے بجائے، کوبلر کا استعمال کرتے ہوئے اس پر OS انسٹال کیا گیا تھا - ٹارگٹ سرور کے میک ایڈریس کوبلر کنفیگریشن میں شامل کیے جاتے ہیں، سرور کو ڈی ایچ سی پی کے ذریعے ایک آئی پی ایڈریس موصول ہوتا ہے، اور پھر OS۔ شامل کیا جاتا ہے.

پہلے تو ہم نے کوبلر میں کسی قسم کا کنفیگریشن مینجمنٹ کرنے کی کوشش کی۔ لیکن وقت گزرنے کے ساتھ، اس سے دوسرے ڈیٹا سینٹرز اور VMs کی تیاری کے لیے جوابی کوڈ دونوں میں کنفیگریشنز کی پورٹیبلٹی کے ساتھ مسائل پیدا ہونے لگے۔

اس وقت، ہم میں سے بہت سے لوگوں نے Ansible کو Bash کی ایک آسان توسیع کے طور پر سمجھا اور شیل اور sed کا استعمال کرتے ہوئے ڈیزائن میں کوتاہی نہیں کی۔ مجموعی طور پر باشیبل۔ یہ بالآخر اس حقیقت کا باعث بنا کہ اگر کسی وجہ سے پلے بک سرور پر کام نہیں کرتی ہے، تو سرور کو حذف کرنا، پلے بک کو ٹھیک کرنا اور اسے دوبارہ چلانا آسان تھا۔ بنیادی طور پر اسکرپٹ کا کوئی ورژن نہیں تھا، کنفیگریشنز کی کوئی پورٹیبلٹی نہیں تھی۔

مثال کے طور پر، ہم تمام سرورز پر کچھ تشکیل تبدیل کرنا چاہتے تھے:

1. ہم منطقی سیگمنٹ/ڈیٹا سینٹر میں موجودہ سرورز پر کنفیگریشن تبدیل کرتے ہیں۔ کبھی کبھی ایک دن میں نہیں - رسائی کے تقاضے اور بڑی تعداد کا قانون تمام تبدیلیوں کو ایک ساتھ لاگو کرنے کی اجازت نہیں دیتا ہے۔ اور کچھ تبدیلیاں ممکنہ طور پر تباہ کن ہیں اور کچھ دوبارہ شروع کرنے کی ضرورت ہوتی ہے - خدمات سے لے کر OS تک۔
2. جواب میں اسے ٹھیک کرنا
3. ہم اسے موچی میں ٹھیک کرتے ہیں۔
4. ہر منطقی سیگمنٹ/ڈیٹا سینٹر کے لیے N بار دہرائیں۔

تمام تبدیلیوں کو آسانی سے چلنے کے لیے، بہت سے عوامل کو مدنظر رکھنا ضروری تھا، اور تبدیلیاں مسلسل ہوتی رہتی ہیں۔

• ریفیکٹرنگ جوابدہ کوڈ، کنفیگریشن فائلز
• اندرونی بہترین طریقوں کو تبدیل کرنا
• واقعات/حادثات کے تجزیہ کے نتائج پر مبنی تبدیلیاں
• اندرونی اور بیرونی سیکورٹی کے معیارات کو تبدیل کرنا۔ مثال کے طور پر، PCI DSS ہر سال نئی ضروریات کے ساتھ اپ ڈیٹ کیا جاتا ہے۔

انفراسٹرکچر کی ترقی اور سفر کا آغاز

سرورز/لوجیکل ڈومینز/ڈیٹا سینٹرز کی تعداد میں اضافہ ہوا، اور ان کے ساتھ کنفیگریشنز میں غلطیوں کی تعداد بڑھی۔ کسی وقت، ہم تین سمتوں پر پہنچے جن میں کنفیگریشن مینجمنٹ کو تیار کرنے کی ضرورت ہے:

1. آٹومیشن. دہرائی جانے والی کارروائیوں میں انسانی غلطی سے حتی الامکان بچنا چاہیے۔
2. تکراری قابلیت۔ انفراسٹرکچر کا انتظام کرنا بہت آسان ہوتا ہے جب یہ پیشین گوئی کے قابل ہو۔ ان کی تیاری کے لیے سرورز اور آلات کی ترتیب ہر جگہ ایک جیسی ہونی چاہیے۔ یہ پروڈکٹ ٹیموں کے لیے بھی اہم ہے - جانچ کے بعد، ایپلیکیشن کو جانچ کے ماحول کی طرح تشکیل شدہ پیداواری ماحول میں ختم کرنے کی ضمانت دی جانی چاہیے۔
3. کنفیگریشن مینجمنٹ میں تبدیلیاں کرنے کی سادگی اور شفافیت۔

یہ ٹولز کے ایک جوڑے کو شامل کرنے کے لئے رہتا ہے.

ہم نے GitLab CE کو اپنے کوڈ ریپوزٹری کے طور پر منتخب کیا، کم از کم اس کے بلٹ ان CI/CD ماڈیولز کے لیے نہیں۔

رازوں کا والٹ - ہاشی کارپ والٹ، بشمول۔ عظیم API کے لیے۔

جانچ کنفیگریشنز اور قابل جواب کردار - مالیکیول + ٹیسٹینفرا۔ اگر آپ جوابدہ مائٹوجن سے منسلک ہوتے ہیں تو ٹیسٹ بہت تیزی سے ہوتے ہیں۔ اسی وقت، ہم نے خود کار طریقے سے تعیناتی کے لیے اپنا سی ایم ڈی بی اور آرکیسٹریٹر لکھنا شروع کیا (کوبلر کے اوپر کی تصویر میں)، لیکن یہ بالکل مختلف کہانی ہے، جو میرے ساتھی اور ان سسٹمز کے مرکزی ڈویلپر مستقبل میں بتائیں گے۔

ہماری پسند:

مالیکیول + ٹیسٹینفرا۔
جوابدہ + ٹاور + AWX
سرورز کی دنیا + DITNET (اپنی ترقی)
موچی
Gitlab + GitLab رنر
ہاشی کارپ والٹ

ویسے، جوابدہ کرداروں کے بارے میں۔ پہلے تو صرف ایک ہی تھا، لیکن کئی ری ایکٹرنگ کے بعد ان میں سے 17 تھے۔ میں پرزور مشورہ دیتا ہوں کہ یک سنگی کو idempotent کرداروں میں توڑ دیا جائے، جسے بعد میں الگ سے لانچ کیا جا سکتا ہے۔ اس کے علاوہ، آپ ٹیگز بھی شامل کر سکتے ہیں۔ ہم نے کرداروں کو فعالیت کے لحاظ سے تقسیم کیا - نیٹ ورک، لاگنگ، پیکجز، ہارڈویئر، مالیکیول وغیرہ۔ عام طور پر، ہم نے ذیل کی حکمت عملی پر عمل کیا۔ میں اصرار نہیں کرتا کہ یہ واحد سچائی ہے، لیکن اس نے ہمارے لیے کام کیا۔

• "گولڈن امیج" سے سرورز کو کاپی کرنا برائی ہے!بنیادی نقصان یہ ہے کہ آپ بالکل نہیں جانتے کہ تصاویر اب کس حالت میں ہیں، اور یہ کہ تمام تبدیلیاں تمام ورچوئلائزیشن فارمز کی تمام تصاویر میں آئیں گی۔
• ڈیفالٹ کنفیگریشن فائلوں کو کم سے کم استعمال کریں اور دوسرے محکموں سے اتفاق کریں کہ آپ مین سسٹم فائلوں کے ذمہ دار ہیں۔مثال کے طور پر:
  1. /etc/sysctl.conf کو خالی چھوڑ دیں، ترتیبات صرف /etc/sysctl.d/ میں ہونی چاہئیں۔ ایک فائل میں آپ کا ڈیفالٹ، دوسری میں درخواست کے لیے حسب ضرورت۔
  2. سسٹمڈ یونٹس میں ترمیم کرنے کے لیے اوور رائڈ فائلز کا استعمال کریں۔
• تمام کنفیگرز کو ٹیمپلیٹ کریں اور انہیں مکمل طور پر شامل کریں؛ اگر ممکن ہو تو، پلے بکس میں کوئی سیڈ یا اس کے اینالاگ نہیں
• کنفیگریشن مینجمنٹ سسٹم کوڈ کو ری فیکٹر کرنا:
  1. کاموں کو منطقی اداروں میں تقسیم کریں اور یک سنگی کو کرداروں میں دوبارہ لکھیں۔
  2. لنٹر استعمال کریں! Ansible-lint، yaml-lint، وغیرہ
  3. اپنا نقطہ نظر تبدیل کریں! کوئی باش نہیں ہے۔ نظام کی حالت کو بیان کرنا ضروری ہے۔
• تمام جوابدہ کرداروں کے لیے آپ کو مالیکیول میں ٹیسٹ لکھنے اور دن میں ایک بار رپورٹ تیار کرنے کی ضرورت ہے۔
• ہمارے معاملے میں، ٹیسٹ کی تیاری کے بعد (جن میں سے 100 سے زیادہ ہیں)، تقریباً 70000 غلطیاں پائی گئیں۔ اسے ٹھیک کرنے میں کئی مہینے لگے۔

ہمارا نفاذ

لہذا، جوابدہ کرداروں کو تیار کیا گیا تھا، نمونہ بنایا گیا تھا اور لنٹرز کے ذریعے چیک کیا گیا تھا۔ اور یہاں تک کہ ہر جگہ گٹس اٹھائے جاتے ہیں۔ لیکن مختلف طبقات کو قابل اعتماد کوڈ کی ترسیل کا سوال کھلا رہا۔ ہم نے اسکرپٹس کے ساتھ مطابقت پذیر ہونے کا فیصلہ کیا۔ ایسا لگتا ہے:

تبدیلی کے آنے کے بعد، CI شروع کیا جاتا ہے، ایک ٹیسٹ سرور بنایا جاتا ہے، رولز کو رول آؤٹ کیا جاتا ہے، اور مالیکیول کے ذریعے ٹیسٹ کیا جاتا ہے۔ اگر سب کچھ ٹھیک ہے تو، کوڈ پروڈ برانچ میں جاتا ہے۔ لیکن ہم مشین میں موجودہ سرورز پر نیا کوڈ لاگو نہیں کرتے ہیں۔ یہ ایک قسم کا سٹاپر ہے جو ہمارے سسٹمز کی اعلیٰ دستیابی کے لیے ضروری ہے۔ اور جب انفراسٹرکچر بہت بڑا ہو جاتا ہے، بڑی تعداد کا قانون کام میں آتا ہے - یہاں تک کہ اگر آپ کو یقین ہے کہ تبدیلی بے ضرر ہے، تو اس کے سنگین نتائج برآمد ہو سکتے ہیں۔

سرور بنانے کے لیے بھی بہت سے اختیارات ہیں۔ ہم نے اپنی مرضی کے مطابق Python اسکرپٹس کا انتخاب کیا۔ اور 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