آئی ٹی ماحول زیادہ سے زیادہ پیچیدہ ہوتا جا رہا ہے۔ ان حالات میں، IT آٹومیشن سسٹم کے لیے ان نوڈس کے بارے میں تازہ ترین معلومات کا ہونا ضروری ہے جو نیٹ ورک میں موجود ہیں اور پروسیسنگ کے تابع ہیں۔ Red Hat Ansible Automation پلیٹ فارم میں، اس مسئلے کو نام نہاد انوینٹری کے ذریعے حل کیا جاتا ہے () - منظم نوڈس کی فہرستیں۔
اس کی آسان ترین شکل میں، انوینٹری ایک جامد فائل ہے۔ جب آپ Ansible کے ساتھ کام کرنا شروع کرتے ہیں تو یہ مثالی ہے، لیکن جیسے جیسے آٹومیشن بڑھتا ہے، یہ ناکافی ہو جاتا ہے۔
اور یہاں کیوں ہے:
- جب چیزیں مسلسل تبدیل ہوتی رہتی ہیں، جب کام کا بوجھ ہوتا ہے — اور اس کے نتیجے میں وہ نوڈس جن پر وہ چلتے ہیں — آتے اور جاتے ہیں تو آپ مانیٹر شدہ نوڈس کی مکمل فہرست کو کیسے اپ ڈیٹ اور برقرار رکھتے ہیں؟
- کسی خاص آٹومیشن کو لاگو کرنے کے لیے خاص طور پر نوڈس کو منتخب کرنے کے لیے آئی ٹی انفراسٹرکچر کے اجزاء کی درجہ بندی کیسے کی جائے؟
متحرک انوینٹری ان دونوں سوالوں کے جوابات فراہم کرتی ہے () – ایک اسکرپٹ یا پلگ ان جو سچائی کے ماخذ کا حوالہ دیتے ہوئے نوڈس کو خودکار ہونے کے لیے تلاش کرتا ہے۔ اس کے علاوہ، متحرک انوینٹری خود بخود نوڈس کو گروپس میں درجہ بندی کرتی ہے تاکہ آپ مخصوص جوابی آٹومیشن کو انجام دینے کے لیے ہدف کے نظام کو زیادہ درست طریقے سے منتخب کر سکیں۔
جوابدہ صارف کو ٹارگٹ نوڈس کو متحرک طور پر تلاش کرنے کے لیے بیرونی پلیٹ فارمز تک رسائی کی صلاحیت فراہم کریں اور انوینٹری بناتے وقت ان پلیٹ فارمز کو سچائی کے ماخذ کے طور پر استعمال کریں۔ Ansible میں ذرائع کی معیاری فہرست میں کلاؤڈ پلیٹ فارم AWS EC2، Google GCP اور Microsoft Azure شامل ہیں، اور Ansible کے لیے بہت سے دوسرے انوینٹری پلگ ان بھی ہیں۔
جواب دینے والا ٹاور ایک نمبر کے ساتھ آتا ہے۔ ، جو بالکل باکس سے باہر کام کرتے ہیں اور اوپر درج کلاؤڈ پلیٹ فارمز کے علاوہ، VMware vCenter، Red Hat OpenStack پلیٹ فارم اور Red Hat سیٹلائٹ کے ساتھ انضمام فراہم کرتے ہیں۔ ان پلگ انز کے لیے، آپ کو ٹارگٹ پلیٹ فارم سے منسلک ہونے کے لیے صرف اسناد فراہم کرنے کی ضرورت ہے، جس کے بعد انہیں جوابی ٹاور میں انوینٹری ڈیٹا کے ذریعہ کے طور پر استعمال کیا جا سکتا ہے۔
Ansible Tower کے ساتھ شامل معیاری پلگ انز کے علاوہ، جوابی کمیونٹی کے تعاون سے دیگر انوینٹری پلگ ان بھی موجود ہیں۔ میں منتقلی کے ساتھ یہ پلگ ان متعلقہ مجموعوں میں شامل ہونے لگے۔
اس پوسٹ میں، ہم ServiceNow کے لیے انوینٹری پلگ ان کے ساتھ کام کرنے کی ایک مثال لیں گے، ایک مشہور IT سروس مینجمنٹ پلیٹ فارم جس میں صارفین اکثر اپنے تمام آلات کے بارے میں معلومات CMDB میں محفوظ کرتے ہیں۔ اس کے علاوہ، سی ایم ڈی بی سیاق و سباق پر مشتمل ہو سکتا ہے جو آٹومیشن کے لیے مفید ہے، جیسے کہ سرور کے مالکان کے بارے میں معلومات، سروس لیول (پروڈکشن/غیر پیداوار)، انسٹال شدہ اپ ڈیٹس، اور مینٹیننس ونڈوز۔ جوابدہ انوینٹری پلگ ان ServiceNow CMDB کے ساتھ کام کر سکتا ہے اور مجموعہ کا حصہ ہے۔ پورٹل پر .
گٹ ذخیرہ
Ansible Tower میں کسی مجموعہ سے انوینٹری پلگ ان استعمال کرنے کے لیے، اسے پروجیکٹ کے ماخذ کے طور پر سیٹ کیا جانا چاہیے۔ جوابی ٹاور میں، ایک پروجیکٹ کسی قسم کے ورژن کنٹرول سسٹم کے ساتھ ایک انضمام ہے، جیسے گٹ ریپوزٹری، جسے نہ صرف آٹومیشن پلے بکس بلکہ متغیرات اور انوینٹری کی فہرستوں کو بھی ہم آہنگ کرنے کے لیے استعمال کیا جا سکتا ہے۔
ہمارا ذخیرہ دراصل بہت آسان ہے:
├── collections
│ └── requirements.yml
└── servicenow.yml
servicenow.yml فائل پلگ ان انوینٹری کی تفصیلات پر مشتمل ہے۔ ہمارے معاملے میں، ہم صرف ServiceNow CMDB میں ٹیبل کی وضاحت کرتے ہیں جسے ہم استعمال کرنا چاہتے ہیں۔ ہم نے وہ فیلڈز بھی سیٹ کیے ہیں جو نوڈ ویری ایبلز کے طور پر شامل کیے جائیں گے، نیز ان گروپس کے بارے میں کچھ معلومات جو ہم بنانا چاہتے ہیں۔
$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
- key: sn_sys_class_name | lower
prefix: ''
separator: ''
- key: sn_os | lower
prefix: ''
separator: ''
براہ کرم نوٹ کریں کہ یہ ServiceNow مثال کی وضاحت نہیں کرتا ہے جس سے ہم کسی بھی طرح سے رابطہ کریں گے، اور کنکشن کے لیے کسی بھی سند کی وضاحت نہیں کرتا ہے۔ ہم یہ سب بعد میں جوابی ٹاور میں ترتیب دیں گے۔
اس کی ضرورت ہے تاکہ جواب دینے والا ٹاور مطلوبہ مجموعہ ڈاؤن لوڈ کر سکے اور اس طرح مطلوبہ انوینٹری پلگ ان حاصل کر سکے۔ بصورت دیگر، ہمیں اپنے تمام جوابی ٹاور نوڈس پر اس مجموعہ کو دستی طور پر انسٹال اور برقرار رکھنا پڑے گا۔
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
ایک بار جب ہم نے اس کنفیگریشن کو ورژن کنٹرول میں دھکیل دیا، تو ہم جوابی ٹاور میں ایک پروجیکٹ بنا سکتے ہیں جو متعلقہ ذخیرہ کا حوالہ دیتا ہے۔ ذیل کی مثال جوابی ٹاور کو ہمارے گیتھب ریپوزٹری سے جوڑتی ہے۔ SCM URL پر توجہ دیں: یہ آپ کو ایک پرائیویٹ ریپوزٹری سے منسلک ہونے کے لیے ایک اکاؤنٹ رجسٹر کرنے کے ساتھ ساتھ ایک مخصوص برانچ، ٹیگ یا چیک آؤٹ کرنے کا عہد کرنے کی اجازت دیتا ہے۔
ServiceNow کے لیے اسناد بنانا
جیسا کہ ذکر کیا گیا ہے، ہمارے ذخیرے کی ترتیب میں ServiceNow سے منسلک ہونے کے لیے اسناد نہیں ہیں اور یہ ServiceNow مثال کی وضاحت نہیں کرتی ہے جس کے ساتھ ہم بات چیت کریں گے۔ لہذا، اس ڈیٹا کو سیٹ کرنے کے لیے، ہم جوابی ٹاور میں اسناد بنائیں گے۔ کے مطابق ، بہت سے ماحولیاتی متغیرات ہیں جن کے ساتھ ہم کنکشن کے پیرامیٹرز مرتب کریں گے، مثال کے طور پر، اس طرح:
= username
The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE
set_via:
env:
- name: SN_USERNAME
اس صورت میں، اگر SN_USERNAME ماحولیاتی متغیر سیٹ ہے، تو انوینٹری پلگ ان اسے ServiceNow سے منسلک کرنے کے لیے بطور اکاؤنٹ استعمال کرے گا۔
ہمیں SN_INSTANCE اور SN_PASSWORD متغیرات کو بھی ترتیب دینے کی ضرورت ہے۔
تاہم، Ansible Tower میں اس قسم کی کوئی اسناد موجود نہیں ہیں جہاں آپ ServiceNow کے لیے اس ڈیٹا کی وضاحت کر سکیں۔ لیکن جوابی ٹاور ہمیں وضاحت کرنے کی اجازت دیتا ہے۔ ، آپ مضمون میں اس کے بارے میں مزید پڑھ سکتے ہیں۔ .
ہمارے معاملے میں، ServiceNow کے لیے حسب ضرورت اسناد کے لیے ان پٹ کنفیگریشن اس طرح نظر آتی ہے:
fields:
- id: SN_USERNAME
type: string
label: Username
- id: SN_PASSWORD
type: string
label: Password
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
یہ اسناد اسی نام کے ساتھ ماحولیاتی متغیرات کے طور پر سامنے آئیں گی۔ یہ انجیکٹر کی ترتیب میں بیان کیا گیا ہے:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
لہذا، ہم نے اس قسم کی تصدیق کی ہے جس کی ہمیں ضرورت ہے، اب ہم ایک ServiceNow اکاؤنٹ شامل کر سکتے ہیں اور مثال، صارف نام اور پاس ورڈ ترتیب دے سکتے ہیں، اس طرح:
ہم انوینٹری بناتے ہیں۔
لہذا، اب ہم سب جوابی ٹاور میں انوینٹری بنانے کے لیے تیار ہیں۔ آئیے اسے سروس ناؤ کہتے ہیں:
انوینٹری بنانے کے بعد، ہم اس کے ساتھ ڈیٹا کا ذریعہ منسلک کر سکتے ہیں۔ یہاں ہم اس پروجیکٹ کی وضاحت کرتے ہیں جو ہم نے پہلے بنایا تھا اور سورس کنٹرول ریپوزٹری میں ہماری YAML انوینٹری فائل کا راستہ داخل کرتے ہیں، ہمارے معاملے میں یہ پروجیکٹ روٹ میں servicenow.yml ہے۔ اس کے علاوہ، آپ کو اپنے ServiceNow اکاؤنٹ کو لنک کرنے کی ضرورت ہے۔
یہ چیک کرنے کے لیے کہ سب کچھ کیسے کام کرتا ہے، آئیے "سب کو ہم آہنگ کریں" بٹن پر کلک کرکے ڈیٹا سورس کے ساتھ ہم آہنگ کرنے کی کوشش کریں۔ اگر سب کچھ صحیح طریقے سے ترتیب دیا گیا ہے، تو نوڈس کو ہماری انوینٹری میں درآمد کیا جانا چاہئے:
براہ کرم نوٹ کریں کہ ہمیں جن گروپس کی ضرورت ہے وہ بھی بنائے گئے ہیں۔
حاصل يہ ہوا
اس پوسٹ میں، ہم نے مثال کے طور پر ServiceNow پلگ ان کا استعمال کرتے ہوئے Ansible Tower میں کلیکشن سے انوینٹری پلگ ان کا استعمال کرنے کا طریقہ دیکھا۔ ہم نے اپنی ServiceNow مثال سے منسلک ہونے کے لیے محفوظ طریقے سے اسناد بھی رجسٹر کی ہیں۔ کسی پروجیکٹ سے انوینٹری پلگ ان کو لنک کرنا نہ صرف فریق ثالث یا کسٹم پلگ ان کے ساتھ کام کرتا ہے بلکہ کچھ معیاری انوینٹریوں کے آپریشن میں ترمیم کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔ یہ جوابدہ آٹومیشن پلیٹ فارم کو موجودہ ٹولز کے ساتھ ضم کرنے کے لیے آسان اور ہموار بناتا ہے جب تیزی سے پیچیدہ IT ماحول کو خودکار کرتا ہے۔
آپ اس پوسٹ میں زیر بحث موضوعات کے ساتھ ساتھ جوابی استعمال کے دیگر پہلوؤں کے بارے میں مزید معلومات یہاں حاصل کر سکتے ہیں:
- کی طرف سے بلاگ .
- .
- آٹومیشن ہب ویب سائٹ پر ریڈ ہیٹ کے تعاون یافتہ مجموعوں کی فہرست ().
- .
*ریڈ ہیٹ اس بات کی کوئی ضمانت نہیں دیتا کہ یہاں موجود کوڈ درست ہے۔ تمام مواد غیر توثیق کی بنیاد پر فراہم کیے جاتے ہیں جب تک کہ واضح طور پر بیان نہ کیا جائے۔
ماخذ: www.habr.com