جوابی میں متغیرات کے لیے سسٹم اپروچ

جوابی ڈیوپس کوڈ اسٹائل

ارے! میرا نام ہے ڈینس کالیوزنی میں ترقیاتی عمل آٹومیشن ڈیپارٹمنٹ میں بطور انجینئر کام کرتا ہوں۔ ہر روز، سیکڑوں مہم سرورز پر نئی ایپلیکیشن بناتی ہیں۔ اور اس مضمون میں میں ان مقاصد کے لیے Ansible کو استعمال کرنے کا اپنا تجربہ بتا رہا ہوں۔

یہ گائیڈ تعیناتی میں متغیرات کو منظم کرنے کا ایک طریقہ پیش کرتا ہے۔ یہ گائیڈ ان لوگوں کے لیے ہے جو پہلے ہی اپنی پلے بکس میں کردار استعمال کرتے ہیں اور پڑھ چکے ہیں۔ بہترین طریقوں، لیکن اسی طرح کے مسائل کا سامنا ہے:

• کوڈ میں متغیر پایا جانے کے بعد، فوری طور پر یہ سمجھنا ناممکن ہے کہ یہ کس چیز کے لیے ذمہ دار ہے؛
• کئی کردار ہیں، اور متغیرات کو ایک قدر کے ساتھ منسلک کرنے کی ضرورت ہے، لیکن یہ کام نہیں کرتا؛
• دوسروں کو سمجھانے میں دشواری ہو رہی ہے کہ آپ کی پلے بکس میں متغیرات کی منطق کیسے کام کرتی ہے۔

ہمیں اپنی کمپنی میں پراجیکٹس پر ان مسائل کا سامنا کرنا پڑا، جس کے نتیجے میں ہم اپنی پلے بکس میں متغیرات کو ڈیزائن کرنے کے اصولوں پر پہنچے، جس سے کسی حد تک یہ مسائل حل ہو گئے۔

کرداروں میں متغیرات

ایک کردار تعیناتی نظام کا ایک الگ آبجیکٹ ہے۔ کسی بھی سسٹم آبجیکٹ کی طرح، اس کا باقی سسٹم کے ساتھ تعامل کے لیے ایک انٹرفیس ہونا چاہیے۔ اس طرح کا انٹرفیس کردار متغیر ہے۔

آئیے مثال کے طور پر کردار کو لیتے ہیں۔ api، جو سرور پر جاوا ایپلیکیشن انسٹال کرتا ہے۔ اس میں کیا متغیرات ہوسکتے ہیں؟

قسم کے لحاظ سے متغیر کرداروں کو 2 اقسام میں تقسیم کیا جا سکتا ہے:

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

متغیر خصوصیات متغیرات ہیں جو کردار کے رویے کا تعین کرتے ہیں۔

استفسار متغیرات - یہ وہ متغیرات ہیں جن کی قدر کو کردار کے بیرونی وسائل کو نامزد کرنے کے لیے استعمال کیا جاتا ہے۔

متغیر سننے والے - یہ وہ متغیرات ہیں جن کی قدر کو درخواست کے متغیرات بنانے کے لیے استعمال کیا جاتا ہے۔

دوسری طرف، 1a، 2a، 2b متغیرات ہیں جو ماحول (ہارڈ ویئر، بیرونی وسائل وغیرہ) پر منحصر نہیں ہیں اور ڈیفالٹ رول میں پہلے سے طے شدہ اقدار سے بھرے جا سکتے ہیں۔ تاہم، قسم 1.b اور 2.c کے متغیرات کو 'مثال' کے علاوہ قدروں سے بھرنا ناممکن ہے، کیونکہ وہ ماحول کے لحاظ سے اسٹینڈ سے اسٹینڈ میں تبدیل ہو جائیں گے۔

کوڈ کا انداز

• متغیر کا نام کردار کے نام سے شروع ہونا چاہیے۔ اس سے مستقبل میں یہ معلوم کرنا آسان ہو جائے گا کہ متغیر کس کردار سے ہے اور اس کے لیے کیا ذمہ دار ہے۔
• کرداروں میں متغیرات کا استعمال کرتے وقت، آپ کو انکیپسولیشن کے اصول پر عمل کرنا یقینی بنانا چاہیے اور خود کردار میں یا ان کرداروں میں متغیرات کا استعمال کریں جن پر موجودہ کا انحصار ہے۔

• متغیرات کے لیے لغات استعمال کرنے سے گریز کریں۔ Ansible آپ کو لغت میں انفرادی اقدار کو آسانی سے اوور رائڈ کرنے کی اجازت نہیں دیتا ہے۔

  خراب متغیر کی مثال:

  myrole_user:
      login: admin
      password: admin

  یہاں لاگ ان آزاد متغیر ہے، اور پاس ورڈ منحصر متغیر ہے۔ لیکن
  چونکہ وہ ایک لغت میں یکجا ہیں، آپ کو اسے مکمل طور پر بیان کرنا پڑے گا۔
  ہمیشہ جو کہ بہت تکلیف دہ ہے۔ اس طرح بہتر:

  myrole_user_login: admin
  myrole_user_password: admin

تعیناتی پلے بکس میں متغیرات

تعیناتی پلے بُک کو مرتب کرتے وقت (جسے بعد میں پلے بُک کہا جاتا ہے)، ہم اس اصول کی پابندی کرتے ہیں کہ اسے الگ ذخیرہ میں رکھا جائے۔ کرداروں کی طرح: ہر ایک اپنے اپنے گٹ ذخیرہ میں۔ یہ آپ کو یہ سمجھنے کی اجازت دیتا ہے کہ رولز اور پلے بک تعیناتی نظام کی مختلف آزاد اشیاء ہیں، اور ایک آبجیکٹ میں ہونے والی تبدیلیوں سے دوسرے کے کام کو متاثر نہیں کرنا چاہیے۔ یہ متغیر کی ڈیفالٹ اقدار کو تبدیل کرکے حاصل کیا جاتا ہے۔

پلے بک کو مرتب کرتے وقت، خلاصہ کرنے کے لیے، رول متغیر کی ڈیفالٹ اقدار کو دو جگہوں پر اوور رائڈ کرنا ممکن ہے: پلے بک متغیرات اور انوینٹری متغیرات میں۔

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - متغیرات اور والٹس

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

یہ نوٹ کرنا ضروری ہے کہ متغیر کی ترجیح آپ کو پہلے پلے بک متغیرات میں متغیرات کو اوور رائڈ کرنے کی اجازت نہیں دے گی اور پھر الگ الگ ایک انوینٹری میں۔

اس کا مطلب یہ ہے کہ پہلے سے ہی اس مرحلے پر یہ فیصلہ کرنا ضروری ہے کہ متغیر ماحول پر منحصر ہے یا نہیں اور اسے مناسب جگہ پر رکھیں۔

مثال کے طور پر، ایک پروجیکٹ میں، SSL کو فعال کرنے کے لیے ذمہ دار متغیر ایک طویل عرصے سے ماحول پر منحصر تھا، کیونکہ ہم SSL کو ان وجوہات میں سے ایک پر فعال نہیں کر سکے جو ہمارے کنٹرول سے باہر ہیں۔ اس مسئلے کو حل کرنے کے بعد، یہ ماحول سے آزاد ہو گیا اور پلے بک متغیرات میں چلا گیا۔

گروپس کے لیے پراپرٹی متغیر

آئیے اپنے ماڈل کو شکل 1 میں ایک مختلف جاوا ایپلیکیشن کے ساتھ، لیکن مختلف سیٹنگز کے ساتھ سرورز کے 2 گروپس کو شامل کرکے پھیلائیں۔

آئیے تصور کریں کہ اس معاملے میں پلے بک کیسی نظر آئے گی:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

ہمارے پلے بک میں تین گروپس ہیں، اس لیے فوری طور پر تجویز کی جاتی ہے کہ گروپ_وارس انوینٹری متغیرات اور پلے بک متغیرات میں اتنی ہی تعداد میں گروپ فائلیں بنائیں۔ اس معاملے میں ایک گروپ فائل پلے بک میں مندرجہ بالا ایپلی کیشن کے ایک جزو کی تفصیل ہے۔ جب آپ پلے بک کے متغیرات میں گروپ فائل کھولتے ہیں، تو آپ کو گروپ پر نصب کرداروں کے پہلے سے طے شدہ رویے سے فوری طور پر تمام فرق نظر آتے ہیں۔ انوینٹری متغیرات میں: اسٹینڈ سے اسٹینڈ تک گروپ کے رویے میں فرق۔

کوڈ سٹائل۔

• host_vars متغیرات کو بالکل بھی استعمال نہ کرنے کی کوشش کریں، کیونکہ وہ سسٹم کی وضاحت نہیں کرتے ہیں، بلکہ صرف ایک خاص معاملہ ہے، جو مستقبل میں سوالات کا باعث بنے گا: "یہ میزبان دوسروں سے مختلف کیوں ہے؟"، جس کا جواب نہیں ہے۔ تلاش کرنے کے لئے ہمیشہ آسان.

مواصلاتی متغیرات

تاہم، یہ وہی ہے جو پراپرٹی متغیرات کے بارے میں ہیں، لیکن مواصلات کے متغیرات کے بارے میں کیا خیال ہے؟
ان کا فرق یہ ہے کہ مختلف گروہوں میں ان کا ایک ہی مطلب ہونا چاہیے۔

پہلے تو یہ تھا۔ خیال ایک راکشسی تعمیر کا استعمال کریں جیسے:
hostvars[groups['bbauth'][0]]['auth_bind_port']لیکن انہوں نے اسے فوراً مسترد کر دیا۔
کیونکہ اس کے نقصانات ہیں. سب سے پہلے، بھاری پن۔ دوم، گروپ میں ایک مخصوص میزبان پر انحصار۔ تیسرا، تعیناتی شروع کرنے سے پہلے، تمام میزبانوں سے حقائق کو جمع کرنا ضروری ہے اگر ہم کسی غیر متعینہ متغیر کی غلطی حاصل نہیں کرنا چاہتے ہیں۔

نتیجے کے طور پر، یہ مواصلاتی متغیرات کو استعمال کرنے کا فیصلہ کیا گیا تھا.

مواصلاتی متغیرات - یہ وہ متغیرات ہیں جو پلے بک سے تعلق رکھتے ہیں اور سسٹم آبجیکٹ کو جوڑنے کے لیے درکار ہیں۔

مواصلاتی متغیرات عام نظام کے متغیرات میں آباد ہوتے ہیں۔ group_vars/all/vars اور ہر گروپ سے تمام سننے والے متغیرات کو ہٹا کر، اور اس گروپ کا نام شامل کر کے بنائے جاتے ہیں جہاں سے سننے والے کو متغیر کے آغاز میں ہٹایا گیا تھا۔

یہ ناموں کی یکسانیت اور غیر اوور لیپنگ کو یقینی بناتا ہے۔

آئیے اوپر دی گئی مثال سے متغیرات کو باندھنے کی کوشش کریں:

آئیے تصور کریں کہ ہمارے پاس متغیرات ہیں جو ایک دوسرے پر منحصر ہیں:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

آئیے اسے عام متغیرات میں ڈالتے ہیں۔ group_vars/all/vars تمام سامعین، اور عنوان میں گروپ کا نام شامل کریں:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

اب، کنیکٹر کی قیمت کو تبدیل کرنے سے، ہم اس بات کو یقینی بنائیں گے کہ درخواست اسی جگہ پر جائے گی جہاں پورٹ واقع ہے۔

کوڈ سٹائل۔

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

ماحولیات پر منحصر فائلیں۔

کردار ایسی فائلوں کا استعمال کر سکتے ہیں جو ماحول سے دوسرے ماحول میں مختلف ہوں۔

ایسی فائلوں کی ایک مثال SSL سرٹیفکیٹ ہے۔ انہیں ٹیکسٹ فارم میں اسٹور کریں۔
ایک متغیر میں بہت آسان نہیں ہے. لیکن ان کے راستے کو متغیر کے اندر محفوظ کرنا آسان ہے۔

مثال کے طور پر، ہم متغیر کا استعمال کرتے ہیں api_ssl_key_file: "/path/to/file".

چونکہ یہ واضح ہے کہ کلیدی سرٹیفکیٹ ماحول سے ماحول میں بدل جائے گا، یہ ماحول پر منحصر متغیر ہے، جس کا مطلب ہے کہ اسے فائل میں موجود ہونا چاہیے۔
group_vars/myapi/vars متغیرات کی انوینٹری، اور 'مثال کے طور پر' قدر پر مشتمل ہے۔

اس معاملے میں سب سے آسان طریقہ یہ ہے کہ کلیدی فائل کو پلے بک ریپوزٹری میں راستے کے ساتھ رکھیں
files/prod/certs/myapi.key، تب متغیر کی قدر ہوگی:
api_ssl_key_file: "prod/certs/myapi.key". سہولت اس حقیقت میں مضمر ہے کہ ایک مخصوص سٹینڈ پر سسٹم کی تعیناتی کے ذمہ دار لوگوں کے پاس بھی اپنی فائلوں کو ذخیرہ کرنے کے لیے ذخیرہ میں اپنی مخصوص جگہ ہوتی ہے۔ ایک ہی وقت میں، سرور پر سرٹیفکیٹ کا مکمل راستہ بتانا ممکن رہتا ہے، اگر سرٹیفکیٹ کسی دوسرے سسٹم کے ذریعے فراہم کیے جاتے ہیں۔

ایک ماحول میں متعدد کھڑے ہیں۔

اکثر ایک ہی ماحول میں کم سے کم فرق کے ساتھ کئی تقریباً ایک جیسے اسٹینڈز کو تعینات کرنے کی ضرورت ہوتی ہے۔ اس صورت میں، ہم ماحول پر منحصر متغیرات کو ان میں تقسیم کرتے ہیں جو اس ماحول میں تبدیل نہیں ہوتے ہیں اور جو بدلتے ہیں۔ اور ہم مؤخر الذکر کو براہ راست انوینٹری فائلوں میں منتقل کرتے ہیں۔ اس ہیرا پھیری کے بعد، ماحولیات کی ڈائرکٹری میں براہ راست ایک اور انوینٹری بنانا ممکن ہو جاتا ہے۔

یہ group_vars انوینٹری کو دوبارہ استعمال کرے گا، اور کچھ متغیرات کو براہ راست اپنے لیے دوبارہ بیان کرنے کے قابل بھی ہوگا۔

تعیناتی منصوبے کے لیے حتمی ڈائریکٹری ڈھانچہ:

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

خلاصہ کرنا

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

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

سسٹم کے منتظمین کو اب تعیناتی کوڈ کو سمجھنے کی ضرورت نہیں ہے۔ کامیاب تعیناتی کے لیے ان کی ضرورت صرف ماحول پر منحصر متغیرات کی فائلوں کو پُر کرنا ہے۔

ادب

1. ریکارڈز

مصنف

Kalyuzhny Denis Alexandrovich

ماخذ: www.habr.com