Ansible playbook یا role: کون سا کب استعمال کریں؟

Ansible playbook اور role میں کیا فرق ہے

Ansible playbook وہ file ہے جسے آپ ansible-playbook کے ساتھ چلاتے ہیں۔ یہ hosts کے ایک group کو مطلوبہ کام سے map کرتی ہے۔ Ansible role ایک fixed layout والی directory ہے، جس میں tasks، templates، handlers اور default variables ہوتے ہیں، اور playbook اسے نام کے ذریعے call کرتی ہے۔ دونوں کے اندر task syntax یکساں ہوتا ہے، اس لیے سوال یہ نہیں کہ آپ کیا express کر سکتے ہیں۔ اصل سوال reuse کا ہے۔

ایک flat playbook سے آغاز کریں۔ ایک site.yml جس میں tasks: list ہو، آپ کی پہلی automation کے لیے درست structure ہے، اور یہ اکثر لوگوں کی توقع سے زیادہ عرصے تک درست رہتا ہے۔ role میں اس وقت منتقل ہوں جب tasks کے اسی block کو hosts کے دوسرے group پر بھی چلانا ہو، یا file تقریباً 100 lines سے بڑی ہو جائے اور scrolling کے ذریعے task تلاش کرنا مشکل ہو جائے۔

اگر آپ نے ابھی تک کوئی playbook نہیں لکھی، تو ایک single VPS کے لیے پہلی playbook سے آغاز کریں اور جب یہ بڑھنے لگے تو واپس آئیں۔

جب flat playbook ہی درست انتخاب ہو

flat playbook اس وقت درست ہوتا ہے جب کام صرف ایک بار یا صرف ایک host پر کیا جائے، یا اسے کوئی اور شخص نہ پڑھے۔ کسی ایک application server کی provisioning کرنا یا maintenance window سے پہلے کسی box پر patches لگانا، ان میں سے کسی کام کے لیے directory tree کی ضرورت نہیں ہوتی۔ ایک role سات directories اور indirection کی ایک اضافی سطح شامل کرتا ہے۔ اگر اسے استعمال کرنے والا واحد caller اس کے ساتھ موجود playbook ہو، تو یہ indirection کوئی فائدہ نہیں دیتی۔ اس کے بجائے جب بھی یہ دیکھنا ہو کہ حقیقت میں کیا چل رہا ہے، ایک اضافی جگہ پر جانا پڑتا ہے۔

flat playbook ایک مخصوص مرحلے پر درست انتخاب نہیں رہتا، اور اس مرحلے کو پہچاننا آسان ہے۔ آپ tasks کے ایک block کو دوسرے playbook میں copy کرتے ہیں۔ یہی copy اس بات کا signal ہے۔ اس کے بعد ہر fix دو بار کرنا پڑتا ہے، اور ایک دن ایسا آتا ہے جب fix صرف ایک جگہ کیا جاتا ہے۔

اصل میں role directory میں کیا ہوتا ہے

roles/common/
  defaults/main.yml
  vars/main.yml
  tasks/main.yml
  handlers/main.yml
  templates/99-hardening.conf.j2
  files/
  meta/main.yml

• tasks/main.yml نقطۂ آغاز ہے۔ Ansible role کو call کیے جانے پر یہ file چلاتا ہے، اور باقی تمام directories اختیاری ہیں۔
• defaults/main.yml میں وہ variables ہوتے ہیں جنہیں caller سے override کرنے کی توقع کی جاتی ہے۔ Ansible میں یہ کم ترین priority والا source ہے، اس لیے تقریباً ہر دوسری چیز اسے override کر دیتی ہے۔
• vars/main.yml میں وہ variables ہوتے ہیں جنہیں caller سے override کرنے کی توقع نہیں کی جاتی۔ Priority میں یہ inventory سے اوپر ہوتا ہے، جو ایک مضبوط پالیسی کا اظہار ہے۔ اسے کم ہی استعمال کریں۔
• handlers/main.yml میں وہ tasks ہوتے ہیں جنہیں notify trigger کرتا ہے۔ Handler play کے اختتام پر ایک بار چلتا ہے، چاہے کتنے ہی tasks اسے notify کریں۔
• files/ میں وہ files ہوتی ہیں جنہیں copy module جوں کا توں copy کرتا ہے، جبکہ templates/ میں وہ Jinja2 templates ہوتے ہیں جنہیں template module render کرتا ہے۔ Role کے اندر دونوں کو صرف bare filename سے reference کریں، path نہ لکھیں، کیونکہ Ansible پہلے role کی اپنی directories میں تلاش کرتا ہے۔
• meta/main.yml role dependencies کی وضاحت کرتا ہے اور وہ metadata فراہم کرتا ہے جسے Ansible Galaxy پڑھتا ہے۔

یہ layout صرف style کی ترجیح نہیں ہے۔ Ansible انہی exact paths میں تلاش کرتا ہے، اس لیے roles/common/template/ (singular) میں رکھی گئی template کبھی نہیں ملے گی۔

ansible-galaxy init کے ذریعے عام role بنائیں

mkdir -p ~/infra/roles
cd ~/infra
ansible-galaxy init --init-path roles common

یہ roles/common کے تحت مکمل skeleton بناتا ہے، جس میں وہ directories بھی شامل ہوتی ہیں جنہیں آپ استعمال نہیں کریں گے، اور main.yml کے ایسے stubs بھی شامل ہوتے ہیں جن میں صرف --- ہوتا ہے۔ جو چیزیں خالی رہ جائیں، انہیں حذف کر دیں۔ خالی vars/main.yml Ansible کے لیے نقصان دہ نہیں ہوتا، لیکن اس سے یہ واضح نہیں رہتا کہ role میں اصل اہمیت کن files کی ہے۔

اب وہ files مکمل کریں جو اصل کام کرتی ہیں۔ پہلے defaults مکمل کریں، کیونکہ یہی role کا public interface ہوتا ہے۔

# roles/common/defaults/main.yml
---
common_packages:
  - ufw
  - fail2ban
  - unattended-upgrades
common_admin_group: admins
common_permit_root_login: "no"
common_password_authentication: "no"

"no" اور "yes" کو quotes میں لکھیں۔ Ansible YAML کو PyYAML کے ذریعے parse کرتا ہے۔ PyYAML بغیر quotes کے no کو boolean false سمجھتا ہے، اس لیے rendered config line PermitRootLogin False بن جاتی ہے اور sshd اسے مسترد کر دیتا ہے۔ Quotes اس value کو string برقرار رکھتے ہیں۔

# roles/common/tasks/main.yml
---
- name: Install the base packages
  ansible.builtin.apt:
    name: "{{ common_packages }}"
    state: present
    update_cache: true
    cache_valid_time: 3600

- name: Create the admin group
  ansible.builtin.group:
    name: "{{ common_admin_group }}"
    state: present

- name: Install the sshd hardening drop-in
  ansible.builtin.template:
    src: 99-hardening.conf.j2
    dest: /etc/ssh/sshd_config.d/99-hardening.conf
    owner: root
    group: root
    mode: "0644"
    validate: /usr/sbin/sshd -t -f %s
  notify: Restart sshd

# roles/common/handlers/main.yml
---
- name: Restart sshd
  ansible.builtin.service:
    name: ssh
    state: restarted

# roles/common/templates/99-hardening.conf.j2
# Managed by Ansible. Local edits are overwritten on the next run.
PermitRootLogin {{ common_permit_root_login }}
PasswordAuthentication {{ common_password_authentication }}

Debian اور Ubuntu پر systemd unit کا نام ssh ہے، جبکہ RHEL family کے systems پر یہ sshd ہے۔ اگر handler میں غلط unit کا نام دیا جائے تو failure صرف اس وقت ظاہر ہوتا ہے جب template میں واقعی کوئی تبدیلی ہو۔ اسی لیے یہ مسئلہ عموماً کئی ہفتے بعد سامنے آتا ہے۔

اس task میں validate line سب سے زیادہ مفید ہے۔ Ansible template کو temporary file میں render کرتا ہے، %s کی جگہ اس file کا path رکھتا ہے، اور command چلاتا ہے۔ Destination file صرف اس وقت replace ہوتی ہے جب command 0 کے ساتھ exit کرے۔ Template میں کوئی غلط directive شامل کر کے دوبارہ چلائیں: task failed to validate کے ساتھ fail ہو جائے گا، اصل /etc/ssh/sshd_config.d/99-hardening.conf میں کوئی تبدیلی نہیں ہوگی، اور آپ کے پاس اب بھی ایسا server ہوگا جس میں login کیا جا سکتا ہے۔ یاد رکھیں کہ یہ check صرف syntax کی جانچ نہیں کرتا۔ اگر sshd -t host keys کو پڑھ نہ سکے تو یہ sshd: no hostkeys available -- exiting. کے ساتھ exit کرتا ہے، اور Ansible وہی failed to validate report کرتا ہے۔ اس لیے template کو موردِ الزام ٹھہرانے سے پہلے module کی msg پڑھیں۔

پلے بُک رول کو کیسے کال کرتی ہے

# site.yml
---
- name: Base configuration for every server
  hosts: all
  become: true
  roles:
    - common

# inventory.ini
[local]
localhost ansible_connection=local

ansible-playbook -i inventory.ini site.yml

Recap میں play کا اختتام failed=0 کے ساتھ ہونا چاہیے۔ کال کی جگہ parameters کو expanded form میں پاس کریں۔ اسی طرح ایک ہی role کو hosts کے دو گروپس کے لیے استعمال کیا جا سکتا ہے:

  roles:
    - role: common
      common_admin_group: ops
      common_permit_root_login: prohibit-password

یہاں ایک ordering rule ہے جو تقریباً سبھی کو حیران کرتا ہے۔ ایک play میں pre_tasks، roles، tasks اور post_tasks شامل ہو سکتے ہیں، اور Ansible انہیں اسی ترتیب سے چلاتا ہے، خواہ آپ نے انہیں file میں کسی بھی ترتیب سے لکھا ہو۔ tasks: کو roles: سے اوپر رکھیں، پھر بھی roles پہلے چلیں گے۔ اس لیے اگر role سے پہلے کچھ ہونا ضروری ہے تو اسے pre_tasks: میں رکھیں، tasks: کے اوپر نہیں۔

- name: Ordering demonstration
  hosts: local
  gather_facts: false
  pre_tasks:
    - name: Runs first
      ansible.builtin.debug:
        msg: pre
  roles:
    - common
  tasks:
    - name: Runs after the role
      ansible.builtin.debug:
        msg: task
  post_tasks:
    - name: Runs last
      ansible.builtin.debug:
        msg: post

roles: key کے بجائے task list کے اندر سے role کو کال کرنے کے لیے import_role یا include_role استعمال کریں۔

  tasks:
    - name: Static, read when the playbook is parsed
      ansible.builtin.import_role:
        name: common

    - name: Dynamic, resolved when the task runs
      ansible.builtin.include_role:
        name: postgres
      when: "'db' in group_names"

import_role static ہے۔ Ansible parse time پر role پڑھتا ہے اور اس کے tasks play کا حصہ بن جاتے ہیں، اس لیے ansible-playbook --list-tasks site.yml انہیں list کرتا ہے اور import پر موجود tag اندر کے ہر task پر لاگو ہوتا ہے۔ include_role dynamic ہے۔ جب تک task run نہیں ہوتا، کچھ بھی read نہیں کیا جاتا۔ اسی وجہ سے role name کو variable یا loop سے متعین کیا جا سکتا ہے۔ اس کا نقصان یہ ہے کہ یہ tasks --list-tasks اور --start-at-task میں نظر نہیں آتے۔

یہاں ایک trap ہے۔ include_role task پر موجود when: کو شامل کیے گئے role کا defaults/main.yml scope میں آنے سے پہلے evaluate کیا جاتا ہے۔ Include پر when: common_packages | length > 0 لکھیں تو run 'common_packages' is undefined کے ساتھ رک جاتا ہے، حالانکہ یہ variable اسی role میں defined ہے جسے آپ include کر رہے ہیں۔ حل یہ ہے کہ toggle کو role سے باہر منتقل کریں۔ اسے group_vars/all.yml میں رکھیں، جہاں یہ ہر جگہ scope میں ہو، اور role کے defaults کو ان values کے لیے رہنے دیں جنہیں خود role استعمال کرتا ہے۔

کون سا variable مؤثر ہوگا: defaults، group_vars، vars، یا extra vars

Ansible variable precedence کی 20 سے زیادہ سطحیں document کرتا ہے۔ ان میں سے چار تقریباً ہر عملی اختلاف کا فیصلہ کر دیتی ہیں۔ کمزور سے مضبوط ترتیب یہ ہے۔

• roles/<name>/defaults/main.yml نچلی سطح کے قریب ہوتا ہے۔ آپ کہیں بھی جو کچھ set کریں گے، تقریباً ہر چیز اسے override کر دے گی۔ اسی لیے role کے قابلِ ترتیب knobs رکھنے کے لیے یہ درست جگہ ہے۔
• group_vars/ اور host_vars/ درمیانی سطح پر ہوتے ہیں۔ آپ کی site کی اپنی values یہاں ہونی چاہییں، اور یہ role defaults کو صاف طور پر override کرتی ہیں۔
• roles/<name>/vars/main.yml، host_vars سے اوپر ہوتا ہے۔ یہاں رکھی گئی value کو inventory سے override نہیں کیا جا سکتا۔ اسے ان values کے لیے محفوظ رکھیں جو role کے اندرونی طور پر consistent رہنا ضروری ہیں، مثلاً ایسا package name جسے service name سے match کرنا ہو۔
• call site پر دیا گیا role parameter، vars/main.yml سے زیادہ مؤثر ہوتا ہے، جبکہ command line پر دیا گیا -e ہر چیز کو، بشمول role parameters کے، override کرتا ہے۔

آپ تقریباً ایک منٹ میں اس precedence کا نتیجہ دیکھ سکتے ہیں۔ ایک چھوٹے role میں ایک default اور ایک role var دیں، پھر host_vars میں وہی names set کریں۔

# roles/prec/defaults/main.yml
---
prec_tunable: from-defaults
prec_internal: from-defaults

# roles/prec/vars/main.yml
---
prec_internal: from-rolevars

# host_vars/localhost.yml
---
prec_tunable: from-hostvars
prec_internal: from-hostvars

# roles/prec/tasks/main.yml
---
- name: Show which value survived
  ansible.builtin.debug:
    msg: "tunable={{ prec_tunable }} internal={{ prec_internal }}"

ansible-playbook -i inventory.ini prec.yml
ansible-playbook -i inventory.ini prec.yml -e prec_internal=from-cli

پہلا run tunable=from-hostvars internal=from-rolevars print کرتا ہے۔ Inventory نے role default کو override کیا، لیکن role var سے کمزور رہی۔ دوسرا run internal=from-cli print کرتا ہے، کیونکہ extra vars سب سے اوپر ہوتے ہیں اور ان سے نیچے کوئی value انہیں override نہیں کر سکتی۔ اسی لیے -e ایک مرتبہ کے run کے لیے مناسب ہے، لیکن ایسے script میں غلط ہے جسے آپ برقرار رکھتے ہیں: یہ repository میں کیے گئے ہر متعلقہ فیصلے کو خاموشی سے override کر دیتا ہے۔

عملی اصول یہ ہے: اگر آپ چاہتے ہیں کہ کوئی value set کی جا سکے تو اسے defaults/ میں رکھیں۔ اسے vars/ میں رکھنے کا مطلب ہر آئندہ user کو یہ بتانا ہے کہ inventory اسے تبدیل نہیں کر سکتی۔ کبھی کبھار یہی آپ کی مراد ہوتی ہے، لیکن عموماً یہ ایک غیر ارادی configuration ہوتی ہے۔

ثابت کریں کہ role idempotent ہے: اسے دو بار چلائیں

قابلِ اعتماد Ansible run دوسری بار وہی نتیجہ دیتا ہے اور رپورٹ کرتا ہے کہ کچھ بھی تبدیل نہیں ہوا۔ playbook کو دو بار چلائیں اور recap پڑھیں۔

ansible-playbook -i inventory.ini site.yml
ansible-playbook -i inventory.ini site.yml

دوسرا recap اس طرح نظر آنا چاہیے:

PLAY RECAP *********************************************************************
localhost   : ok=4  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

changed=0 کا مطلب ہے کہ ہر module نے موجودہ حالت کا جائزہ لیا اور پایا کہ مطلوبہ کام پہلے ہی مکمل ہے۔ دوسری run میں changed=2 کا مطلب ہے کہ دو tasks فرق معلوم نہیں کر سکتے، اس لیے وہ فائلیں دوبارہ لکھتے اور services کو ہمیشہ restart کرتے رہیں گے۔ عموماً وجہ command یا shell ہوتی ہے، کیونکہ Ansible کے پاس یہ معلوم کرنے کا طریقہ نہیں ہوتا کہ کسی من مانے command نے کیا کیا۔

# traps.yml
---
- name: Command modules do not know what they changed
  hosts: local
  gather_facts: false
  tasks:
    - name: This appends a line on every run
      ansible.builtin.shell: "echo run >> /tmp/grow.txt"

    - name: This appends a line only once
      ansible.builtin.shell: "echo run >> /tmp/guarded.txt"
      args:
        creates: /tmp/guarded.txt

اس playbook کو دو بار چلائیں، پھر wc -l /tmp/grow.txt /tmp/guarded.txt والی lines گنیں۔ /tmp/grow.txt میں دو lines اور /tmp/guarded.txt میں ایک line ہونی چاہیے۔ دوسری run میں guarded task بالکل execute نہیں ہوا، اور اس کے result میں skipped, since /tmp/guarded.txt exists message موجود ہے، کیونکہ creates module کو پہلے تلاش کرنے کے لیے ایک قابلِ مشاہدہ نتیجہ فراہم کرتا ہے۔ جب command ایسا کوئی نتیجہ پیدا نہ کرے تو اس کا output changed_when کے ساتھ register کریں اور خود فیصلہ کریں۔

ansible-playbook --check --diff site.yml تبدیلیاں کیے بغیر ان کی پیش گوئی کرتا ہے، جبکہ --diff وہ exact lines دکھاتا ہے جنہیں template دوبارہ لکھے گا۔ output پڑھتے وقت ایک بات ذہن میں رکھیں: shell اور command tasks check mode میں skip ہو جاتے ہیں، اس لیے بظاہر صاف plan میں بھی کام پوشیدہ رہ سکتا ہے۔

Ansible کیوں کہتا ہے کہ role نہیں ملی

Ansible پہلے playbook فائل کے ساتھ موجود roles/ ڈائریکٹری میں، پھر roles_path میں تلاش کرتا ہے۔ یہ تلاش آپ کے shell کے بجائے playbook کی پیروی کرتی ہے۔

ERROR! the role 'common' was not found in /home/deploy/lonely/roles:/home/deploy/lonely

اس پیغام کا مطلب ہے کہ site.yml اور roles/ ایک دوسرے سے مطابقت نہیں رکھتے، اور پیغام ان paths کو بھی دکھاتا ہے جہاں تلاش کی گئی۔ دونوں کو ایک ہی ڈائریکٹری میں رکھیں۔ Parent directory سے run کرنا درست ہے، کیونکہ اہم playbook path ہوتا ہے:

ansible-playbook -i infra/inventory.ini infra/site.yml

اسی مسئلے کی ایک کم نمایاں صورت بھی ہے۔ اگر موجودہ ڈائریکٹری world writable ہو تو Ansible اس میں موجود ansible.cfg کو نظر انداز کرتا ہے، کیونکہ server کا کوئی بھی user وہاں configuration رکھ کر آپ کے run کے نتائج تبدیل کر سکتا ہے۔

[WARNING]: Ansible is being run in a world writable directory (/tmp/infra), ignoring it as an ansible.cfg source.

اس صورت میں آپ کی roles_path اور inventory settings خاموشی سے غیر موجود رہتی ہیں، اور role lookup ایسی وجہ سے ناکام ہوتی ہے جس کا roles سے کوئی تعلق نہیں ہوتا۔ ansible --version وہ config file دکھاتا ہے جسے اس نے حقیقت میں load کیا۔ ansible-config dump --only-changed ہر وہ setting دکھاتا ہے جو built-in defaults سے مختلف ہو۔ جب run اس طرح عمل کرے جیسے آپ کی configuration موجود نہیں، تو دونوں کو check کریں۔

Roles کا اشتراک: requirements.yml اور pinned version

کسی دوسرے شخص کی لکھی ہوئی role کو copy نہیں کیا جاتا بلکہ install کیا جاتا ہے۔ اسے ایک بار declare کریں:

# requirements.yml
---
roles:
  - name: postgres
    src: https://github.com/example/ansible-role-postgres
    scm: git
    version: v1.4.0

ansible-galaxy install -r requirements.yml -p galaxy_roles

ہمیشہ version مقرر کریں۔ اس کے بغیر command چلانے کے دن default branch میں موجود version حاصل ہوتی ہے۔ اس لیے جو deployment گزشتہ ماہ کامیاب تھی، وہ آپ کی اپنی repository میں کسی تبدیلی کے بغیر ناکام ہو سکتی ہے۔ roles_path کو download directory پر مقرر کریں، اور اس directory کو git سے خارج رکھیں:

# ansible.cfg
[defaults]
inventory = inventory.ini
roles_path = ./galaxy_roles

Playbook کے ساتھ موجود roles/ میں رکھی roles پھر بھی مل جاتی ہیں، کیونکہ اس path کو roles_path کے علاوہ ہمیشہ تلاش کیا جاتا ہے۔ اس طرح آپ کی اپنی roles repository میں committed اور review شدہ رہتی ہیں، جبکہ third-party roles tag سے pinned reproducible downloads ہوتی ہیں۔

جہاں roles جواب نہیں رہتے

role ایک ہی Ansible run کے اندر دوبارہ استعمال کی جانے والی اکائی ہے۔ یہ آپ کے provider پر servers یا DNS records نہیں بناتی، اور اسے ایسا کرنے پر مجبور کرنا ہی playbooks کو ایسی چیز میں بدل دیتا ہے جسے کوئی maintain نہیں کرنا چاہتا۔ شروع کرنے سے پہلے Ansible اور Terraform کے درمیان کام کی تقسیم پڑھ لینا مفید ہے۔ role inventory design کا متبادل بھی نہیں ہے: چند machines سے آگے بڑھنے کے بعد ان servers کو group اور access کرنے کا طریقہ اس بات سے زیادہ اہم ہو جاتا ہے کہ tasks کو کس طرح file کیا گیا ہے۔

یہ common role جو hardening install کرتی ہے، اس کے لیے بھی الگ فیصلے درکار ہیں۔ اوپر دیا گیا drop-in صرف دو directives set کرتا ہے، اس سے زیادہ نہیں۔ اس لیے ہر اپنے host کے لیے role میں شامل کی جانے والی settings طے کرنے سے پہلے کون سی SSH settings واقعی تبدیل کرنے کے قابل ہیں اور Ubuntu کو security updates خودکار طور پر apply کرنے کا طریقہ پڑھیں۔

FAQ

مجھے Ansible playbook کو role میں کب تبدیل کرنا چاہیے؟

جب tasks کے اسی block کو دوسری play میں یا hosts کے دوسرے group کے خلاف چلانا ہو۔ playbooks کے درمیان tasks copy کرنا اس کی علامت ہے، کیونکہ اس وقت سے ہر fix دو بار لاگو کرنا پڑتا ہے، اور کسی دن یہ صرف ایک جگہ لاگو ہوگا۔ تقریباً 100 lines سے کم ایک ایسا playbook جو ہمیشہ صرف ایک group کو target کرتا ہو، role سے کوئی فائدہ حاصل نہیں کرتا۔ اضافی directories اسے پڑھنا مشکل بنا دیتی ہیں۔

کیا اسی play میں موجود tasks سے پہلے roles چلتے ہیں؟

ہاں۔ Ansible پہلے pre_tasks چلاتا ہے، پھر roles: کے تحت درج تمام چیزیں، اس کے بعد tasks:، اور آخر میں post_tasks:۔ یہ آپ کی file میں ان keys کی ترتیب کو نظرانداز کرتا ہے۔ tasks: کو roles: کے اوپر لکھنے سے وہ tasks پہلے نہیں چلیں گے۔ اگر کچھ role سے پہلے ہونا ضروری ہو تو اسے pre_tasks: میں رکھیں۔

میری group_vars کی value role کو override کیوں نہیں کرتی؟

دیکھیں کہ variable role کے vars/main.yml میں set ہے یا defaults/main.yml میں۔ Ansible کی precedence order میں vars/، group_vars اور host_vars سے اوپر ہوتا ہے، اس لیے inventory اسے override نہیں کر سکتی۔ variable کو defaults/main.yml میں منتقل کریں۔ یہ precedence order کے نچلے حصے کے قریب ہے اور ایسی ہر value کے لیے درست جگہ ہے جسے caller تبدیل کر سکے۔ یہ تصدیق کرنے کے لیے کہ وجہ precedence ہے، typo نہیں، ایک بار -e name=value کے ساتھ چلائیں۔ اس کی precedence ہر دوسرے source سے زیادہ ہے۔

Ansible role نہ ملنے کا پیغام کیوں دیتا ہے؟

Search playbook file کے ساتھ والی جگہ سے شروع ہوتا ہے، اس لیے site.yml اور roles/ ایک ہی directory میں ہونے چاہییں۔ Error میں وہ paths دکھائے جاتے ہیں جنہیں آزمایا گیا، جیسا کہ the role 'common' was not found in /home/deploy/lonely/roles:/home/deploy/lonely میں ہے۔ playbook کو parent directory سے چلانا درست ہے، کیونکہ search playbook path کی پیروی کرتا ہے، shell کی working directory کی نہیں۔ اگر آپ ansible.cfg سے roles_path پر انحصار کرتے ہیں تو تصدیق کریں کہ وہ file ansible --version کے ذریعے load ہوئی ہے، کیونکہ world-writable working directory کی صورت میں Ansible اسے نظرانداز کر دیتا ہے۔

کیا role بنانے کے لیے ansible-galaxy init ضروری ہے؟

نہیں۔ role صرف متوقع ناموں والی directories پر مشتمل ہوتی ہے، اس لیے mkdir -p roles/common/tasks اور ایک tasks/main.yml پہلے ہی کام کرنے والی role بناتے ہیں۔ ansible-galaxy init --init-path roles common typing کم کرتا ہے اور مکمل skeleton فراہم کرتا ہے، جس میں meta/main.yml اور README کا ابتدائی متن بھی شامل ہے۔ جن directories کو خالی چھوڑیں انہیں delete کر دیں، کیونکہ خالی vars/main.yml سے یہ معلوم کرنا مشکل ہو جاتا ہے کہ role میں واقعی کون سی files کام کرتی ہیں۔