Ansible playbook లేదా role: ఏది ఎప్పుడు వాడాలి?

Ansible playbook vs role: తేడా ఏమిటి

Ansible playbook అనేది మీరు ansible-playbook తో అమలు చేసే ఫైల్. ఇది ఒక సమూహం hosts కు అవసరమైన పనులను కేటాయిస్తుంది. Ansible role అనేది నిర్ణీత నిర్మాణం కలిగిన directory. ఇందులో tasks, templates, handlers మరియు default variables ఉంటాయి. playbook దీనిని పేరుతో పిలుస్తుంది. రెండింటిలోనూ task syntax ఒకటే. కాబట్టి ఇది ఏమి వ్యక్తీకరించగలరనే ప్రశ్న కాదు. ఇది పునర్వినియోగం గురించి.

మొదట సాదా playbook తో ప్రారంభించండి. ఒక site.yml లో tasks: list ఉండటం మీ మొదటి automation కు సరైన నిర్మాణం. చాలా మంది ఊహించిన దానికంటే ఇది ఎక్కువకాలం సరైనదిగానే ఉంటుంది. అదే tasks block రెండవ hosts సమూహంలో కూడా అమలు చేయాల్సి వచ్చినప్పుడు, లేదా ఫైల్ సుమారు 100 lines ను దాటినప్పుడు మరియు scrolling ద్వారా task ను కనుగొనలేనప్పుడు role కు మార్చండి.

మీరు ఇంకా ఒకదాన్ని రాయలేదా? ఒకే VPS పై మొదటి playbook తో ప్రారంభించండి; అది పెరగడం ప్రారంభించినప్పుడు తిరిగి రండి.

flat playbook సరైన ఎంపిక అయినప్పుడు

పని ఒక్కసారి మాత్రమే జరిగితే, లేదా ఒకే hostపై జరిగితే, లేదా దాన్ని మరెవరూ చదవకపోతే flat playbook సరైనది. ఒకే application serverను provision చేయడం లేదా maintenance windowకు ముందు ఒక boxకు patchలు వేయడం వంటి పనులకు directory tree అవసరం లేదు. ఒక role ఏడు directoriesను, ఒక అదనపు abstraction పొరను జోడిస్తుంది. దాన్ని ఉపయోగించేది పక్కనే ఉన్న playbook ఒక్కటే అయితే, ఆ abstraction వల్ల ప్రయోజనం ఉండదు. నిజంగా ఏది అమలవుతుందో చదవాలనుకున్న ప్రతిసారీ అదనపు దశను దాటాలి.

ఒక నిర్దిష్ట దశలో flat playbook సరైన ఎంపికగా ఉండదు. ఆ దశను సులభంగా గుర్తించవచ్చు. మీరు tasksలోని ఒక blockను రెండో playbookలోకి copy చేస్తారు. అదే ఆ మార్పుకు సంకేతం. అప్పటి నుంచి ప్రతి పరిష్కారాన్ని రెండుసార్లు చేయాలి. ఒక రోజు అది ఒక్కసారి మాత్రమే చేయబడుతుంది.

పాత్ర డైరెక్టరీలో వాస్తవంగా ఏమి ఉంటుంది

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 ఈ ఫైల్‌ను అమలు చేస్తుంది. మిగతా ప్రతి డైరెక్టరీ ఐచ్ఛికం.
• defaults/main.yml లో caller override చేయాల్సి ఉంటుందని భావించే variables ఉంటాయి. Ansibleలో ఇది అత్యల్ప ప్రాధాన్యత కలిగిన మూలం. అందువల్ల దాదాపు ఏ ఇతర మూలమైనా దీనిని అధిగమిస్తుంది.
• vars/main.yml లో caller override చేయాల్సిన అవసరం లేదని భావించే variables ఉంటాయి. ప్రాధాన్యతలో ఇది inventory కంటే పై స్థాయిలో ఉంటుంది. ఇది బలమైన ప్రభావం కలిగించే అమరిక. దీన్ని అరుదుగా ఉపయోగించండి.
• handlers/main.yml లో notify ద్వారా trigger చేయబడే tasks ఉంటాయి. handlerను ఎన్ని tasks notify చేసినా, అది play చివరలో ఒకసారి మాత్రమే అమలవుతుంది.
• files/ లో copy moduleతో ఉన్నట్టుండి copy చేసే files ఉంటాయి. templates/ లో template moduleతో render చేసే Jinja2 templates ఉంటాయి. పాత్రలో వీటిని path లేకుండా bare filenameతో reference చేయండి. Ansible ముందుగా పాత్రకు చెందిన directoriesలో శోధిస్తుంది.
• meta/main.yml పాత్ర dependenciesను ప్రకటిస్తుంది. Ansible Galaxy చదివే metadataను కూడా ఇది కలిగి ఉంటుంది.

ఈ layout కేవలం శైలి ఎంపిక కాదు. Ansible ఈ ఖచ్చితమైన pathsలోనే శోధిస్తుంది. అందువల్ల roles/common/template/ (ఏకవచనం)లో ఉంచిన 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 bare no ను boolean falseగా చదువుతుంది. అందువల్ల రూపొందిన config line PermitRootLogin False గా మారుతుంది, ఆపై sshd దాన్ని తిరస్కరిస్తుంది. Quotes ఆ విలువను 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. Templateలో నిజంగా మార్పు జరిగినప్పుడు మాత్రమే తప్పు unit పేరును ఉపయోగించిన handler విఫలమవుతుంది. అందుకే ఈ సమస్య సాధారణంగా కొన్ని వారాల తర్వాత బయటపడుతుంది.

ఆ taskలో validate line అత్యంత ఉపయోగకరమైనది. Ansible templateను temporary fileలో render చేస్తుంది, ఆ file pathను %s స్థానంలో ఉంచి commandను అమలు చేస్తుంది. Command 0తో exit అయినప్పుడు మాత్రమే destinationను భర్తీ చేస్తుంది. Templateలో అర్థంలేని directiveను ఉంచి మళ్లీ run చేయండి. Task failed to validateతో విఫలమవుతుంది, అసలు /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ను చదవండి.

ప్లేబుక్ ఒక role ను ఎలా పిలుస్తుంది

# 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 లో failed=0 తో play ముగియాలి. call site వద్ద expanded form ఉపయోగించి parameters పంపండి. దీనివల్ల ఒక role రెండు host సమూహాలకు ఉపయోగపడుతుంది:

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

దాదాపు అందరినీ ఆశ్చర్యపరిచే ఒక ordering rule ఉంది. ఒక play లో pre_tasks, roles, tasks మరియు post_tasks ఉండవచ్చు. ఫైల్‌లో మీరు వాటిని ఏ క్రమంలో రాసినా, Ansible వాటిని అదే క్రమంలో నడుపుతుంది. tasks: ను roles: పైన ఉంచినా, roles ముందుగా నడుస్తాయి. కాబట్టి role కు ముందు ఏదైనా జరగాలంటే, అది tasks: పైభాగంలో కాకుండా pre_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 వాటిని జాబితా చేస్తుంది. import పై ఉన్న tag లోపలి ప్రతి task కు వర్తిస్తుంది. include_role dynamic. task నడిచే వరకు ఏదీ చదవబడదు. అందువల్ల role name ను variable లేదా loop నుంచి నిర్ణయించవచ్చు. అయితే ఈ tasks --list-tasks మరియు --start-at-task కు కనిపించవు.

ఇక్కడ ఒక ముఖ్యమైన పొరపాటు అవకాశం ఉంది. include_role task పై ఉన్న when:, చేర్చిన role యొక్క defaults/main.yml scope లోకి రావడానికి ముందే మూల్యాంకనం చేయబడుతుంది. include పై when: common_packages | length > 0 రాస్తే, 'common_packages' is undefined తో run ఆగిపోతుంది. ఆ variable మీరు చేర్చుతున్న role లోనే నిర్వచించినప్పటికీ ఇది జరుగుతుంది. దీనికి పరిష్కారం toggle ను role వెలుపలికి తరలించడం. దాన్ని group_vars/all.yml లో ఉంచండి. అప్పుడు అది ప్రతిచోటా scope లో ఉంటుంది. Role స్వయంగా ఉపయోగించే విలువల కోసం మాత్రమే role యొక్క defaults ను ఉంచండి.

ఏ వేరియబుల్ ప్రాధాన్యం పొందుతుంది: defaults, group_vars, vars, extra vars

Ansibleలో వేరియబుల్ ప్రాధాన్యానికి ఇరవైకి పైగా స్థాయిలు ఉన్నాయి. వాస్తవ వినియోగంలోని దాదాపు ప్రతి వివాదాన్ని నాలుగు స్థాయిలు పరిష్కరిస్తాయి. అవి బలహీనమైనవి నుంచి బలమైనవి వరకు ఇలా ఉన్నాయి.

• roles/<name>/defaults/main.yml దిగువ భాగంలో ఉంటుంది. మీరు మరెక్కడైనా సెట్ చేసిన దాదాపు ఏ విలువైనా దీనిపై ప్రాధాన్యం పొందుతుంది. అందుకే roleలో మార్చగల సెట్టింగ్‌లకు ఇది సరైన స్థానం.
• group_vars/ మరియు host_vars/ మధ్యస్థానంలో ఉంటాయి. మీ siteకి సంబంధించిన విలువలను ఇక్కడ ఉంచాలి. ఇవి role defaultsను స్పష్టంగా override చేస్తాయి.
• roles/<name>/vars/main.yml, host_vars కంటే పైస్థానంలో ఉంటుంది. ఇక్కడ ఉంచిన విలువను inventory ద్వారా override చేయలేరు. role అంతర్గతంగా ఒకే విధంగా ఉండటానికి అవసరమైన విషయాలకు దీన్ని కేటాయించండి. ఉదాహరణకు, service పేరుతో సరిపోలాల్సిన package పేరు.
• call site వద్ద అందించిన role parameter, vars/main.yml కంటే ప్రాధాన్యం పొందుతుంది. కమాండ్ లైన్‌లోని -e, role parametersతో సహా మిగతా అన్నింటికంటే ప్రాధాన్యం పొందుతుంది.

ఇది ఎలా పరిష్కరించబడుతుందో సుమారు ఒక నిమిషంలో చూడవచ్చు. ఒక చిన్న roleలో ఒక default మరియు ఒక role var ఇవ్వండి. తర్వాత అదే పేర్లను host_varsలో సెట్ చేయండి.

# 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 ముద్రించబడుతుంది. Inventory, role defaultపై ప్రాధాన్యం పొందింది. అయితే role var చేతిలో ఓడిపోయింది. రెండో runలో internal=from-cli ముద్రించబడుతుంది. ఎందుకంటే extra vars అత్యున్నత స్థాయిలో ఉంటాయి. వాటి కంటే దిగువన ఉన్న ఏ విలువా వాటిని మార్చలేను. అందుకే ఒక్కసారి మాత్రమే చేసే runకు -e అనుకూలంగా ఉంటుంది. అయితే నిరంతరం ఉపయోగించే scriptలో ఇది తప్పు. మీ repositoryలో పరిశీలించిన ప్రతి నిర్ణయానికంటే ఇది నిశ్శబ్దంగా అధిక ప్రాధాన్యం పొందుతుంది.

ఆచరణ నియమం: ఒక విలువను మార్చగలిగేలా ఉంచాలనుకుంటే, దాన్ని defaults/లో ఉంచండి. దాన్ని vars/లో ఉంచడం ద్వారా roleను ఉపయోగించే భవిష్యత్ ప్రతి వినియోగదారుకూ inventory ద్వారా దాన్ని మార్చలేమని తెలియజేస్తారు. కొన్నిసార్లు ఇదే మీ ఉద్దేశం కావచ్చు. సాధారణంగా ఇది అనుకోకుండా జరుగుతుంది.

పాత్ర idempotent అని నిరూపించండి: దీన్ని రెండుసార్లు అమలు చేయండి

విశ్వసించదగిన Ansible అమలు రెండోసారి కూడా అదే ఫలితాన్ని ఇస్తుంది మరియు ఏదీ మారలేదని నివేదిస్తుంది. 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 ప్రస్తుత స్థితిని తనిఖీ చేసి, అవసరమైన పని ఇప్పటికే పూర్తయిందని గుర్తించింది. రెండో అమలులో changed=2 కనిపిస్తే, రెండు tasks తేడాను గుర్తించలేకపోతున్నాయని అర్థం. అందువల్ల అవి ఎప్పటికీ files ను మళ్లీ రాస్తూ, services ను పునఃప్రారంభిస్తూనే ఉంటాయి. సాధారణ కారణం command లేదా shell. ఎందుకంటే arbitrary command ఏమి చేసిందో Ansible తెలుసుకోలదు.

# 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 ఉంటుంది. రెండో అమలులో guarded task అసలు execute కాలేదు. దాని result లో skipped, since /tmp/guarded.txt exists అనే message ఉంటుంది. ఎందుకంటే creates module కు ముందుగా చూడవలసిన స్పష్టమైన ఉత్పత్తిని అందిస్తుంది. Command అలాంటి ఉత్పత్తిని సృష్టించనప్పుడు, దాని output ను register చేసి changed_when తో మీరే నిర్ణయించండి.

ansible-playbook --check --diff site.yml మార్పులు చేయకుండా అవి ఏవో అంచనా వేస్తుంది. --diff template మళ్లీ రాయబోయే ఖచ్చితమైన lines ను ముద్రిస్తుంది. Output ను చదివేటప్పుడు ఒక విషయాన్ని గుర్తుంచుకోండి: check mode లో shell మరియు command tasks skip అవుతాయి. అందువల్ల శుభ్రంగా కనిపించే plan లో కూడా ఇంకా చేయాల్సిన పని దాగి ఉండవచ్చు.

Ansible పాత్ర కనుగొనబడలేదని ఎందుకు చెబుతుంది

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/ మధ్య సమన్వయం తప్పిపోయిందని సూచిస్తుంది. ఇది ప్రయత్నించిన మార్గాలను కూడా చూపిస్తుంది. ఈ రెండింటినీ ఒకే డైరెక్టరీలో ఉంచండి. Parent directory నుంచి అమలు చేయడం సమస్య కాదు, ఎందుకంటే పరిగణనలోకి వచ్చేది playbook మార్గమే:

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

ఇదే సమస్యకు మరింత నిశ్శబ్దమైన రూపం కూడా ఉంది. ప్రస్తుత డైరెక్టరీ world writableగా ఉంటే, Ansible ఆ డైరెక్టరీలోని ansible.cfg ను పట్టించుకోదు. ఎందుకంటే ఆ సిస్టమ్‌లోని ఏ వినియోగదారైనా అక్కడ 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 నిశ్శబ్దంగా అందుబాటులో ఉండవు. పాత్ర lookup విఫలమవుతుంది, కానీ దానికి roles‌తో సంబంధం ఉండదు. ansible --version వాస్తవంగా లోడ్ చేసిన config file ను చూపిస్తుంది. ansible-config dump --only-changed built-in defaults‌తో భిన్నంగా ఉన్న ప్రతి setting‌ను చూపిస్తుంది. మీ configuration ఉన్నట్లుగా run ప్రవర్తించనప్పుడు ఈ రెండింటినీ తనిఖీ చేయండి.

Sharing roles: requirements.yml and a pinned version

వేరొకరు రాసిన role‌ను కాపీ చేయరు; దాన్ని ఇన్‌స్టాల్ చేస్తారు. దాన్ని ఒక్కసారి ప్రకటించండి:

# 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 కూడా కనుగొనబడతాయి. ఎందుకంటే roles_path తో పాటు ఆ pathను ఎల్లప్పుడూ శోధిస్తారు. కాబట్టి మీ స్వంత roles commit చేసి review చేయవచ్చు. Third-party roles మాత్రం tagకు pin చేసిన, పునరుత్పత్తి చేయగల downloadsగా ఉంటాయి.

పాత్రలతో పరిష్కరించలేని విషయాలు

ఒకే Ansible runలో పునర్వినియోగించగల యూనిట్‌గా role పనిచేస్తుంది. ఇది మీ provider వద్ద servers లేదా DNS records సృష్టించదు. దాన్ని అలా చేయించడానికి ప్రయత్నిస్తే, playbooksను ఎవరూ నిర్వహించాలనుకోని స్థితికి తీసుకెళ్తారు. ప్రారంభించే ముందు Ansible మరియు Terraform మధ్య పనిని ఎలా విభజించాలి అనే అంశాన్ని చదవడం ఉపయోగకరం. role inventory designకు కూడా ప్రత్యామ్నాయం కాదు. కొన్ని machinesను దాటిన తర్వాత, ఆ serversను ఎలా group చేసి చేరుకోవాలి అనేది tasksను ఎలా ఫైల్ చేశారన్నదానికంటే ముఖ్యంగా మారుతుంది.

ఈ common role అమలు చేసే hardeningకు కూడా ప్రత్యేక నిర్ణయాలు అవసరం. పై drop-in రెండు directivesను మాత్రమే సెట్ చేస్తుంది. అందువల్ల, ప్రతి hostకు roleలో ఏమి ఉంచాలో నిర్ణయించే ముందు ఏ SSH settingsను మార్చడం నిజంగా విలువైనది మరియు Ubuntu security updatesను స్వయంగా apply చేసేలా ఎలా చేయాలి అనే అంశాలను చదవండి.

FAQ

Ansible playbook‌ను ఎప్పుడు role‌గా మార్చాలి?

అదే tasks బ్లాక్‌ను రెండవ play‌లో లేదా రెండవ hosts group‌పై అమలు చేయాల్సి వచ్చినప్పుడు మార్చాలి. Playbooks మధ్య tasks‌ను copy చేయడం దీనికి సంకేతం. ఆ దశ నుంచి ప్రతి పరిష్కారాన్ని రెండుసార్లు వర్తింపజేయాలి. ఏదో ఒక రోజు అది ఒక్కసారి మాత్రమే వర్తించే అవకాశం ఉంది. సుమారు 100 lines కంటే తక్కువగా ఉండి, ఎల్లప్పుడూ ఒకే group‌ను target చేసే single playbook‌కు role వల్ల ప్రయోజనం ఉండదు. అదనపు directories దాన్ని చదవడం కష్టతరం చేస్తాయి.

అదే play‌లోని tasks‌కు ముందు roles అమలవుతాయా?

అవును. Ansible ముందుగా pre_tasksను, తర్వాత roles: కింద ఉన్న ప్రతిదాన్ని, ఆపై tasks:ను, తర్వాత post_tasks:ను అమలు చేస్తుంది. మీ file‌లో ఈ keys కనిపించే క్రమాన్ని అది పట్టించుకోదు. tasks:ను roles: పైన రాయడం వల్ల ఆ tasks ముందుగా అమలుకావు. ఏదైనా role‌కు ముందు అమలు కావాల్సి ఉంటే, దాన్ని pre_tasks:లో ఉంచండి.

నా group_vars విలువ role‌ను ఎందుకు override చేయడం లేదు?

ఆ variable role‌లోని vars/main.ymlలో సెట్ అయిందా, defaults/main.ymlలో సెట్ అయిందా తనిఖీ చేయండి. Ansible precedence order‌లో vars/, group_vars మరియు host_vars కంటే పై స్థాయిలో ఉంటుంది. అందువల్ల inventory దాన్ని override చేయలేదు. ఆ variable‌ను defaults/main.ymlకు తరలించండి. ఇది precedence order‌లో దిగువ భాగానికి సమీపంలో ఉంటుంది. Caller మార్చగలిగే ఏ విలువకైనా ఇదే సరైన స్థానం. Typo కారణం కాకుండా precedence కారణమని నిర్ధారించడానికి, -e name=valueతో ఒక్కసారి అమలు చేయండి. ఇది ఇతర ప్రతి source కంటే అధిక precedence కలిగి ఉంటుంది.

Role కనుగొనబడలేదని Ansible ఎందుకు చెబుతోంది?

Search playbook file పక్కన ప్రారంభమవుతుంది. అందువల్ల site.yml మరియు roles/ ఒకే directoryలో ఉండాలి. Error ప్రయత్నించిన paths‌ను the role 'common' was not found in /home/deploy/lonely/roles:/home/deploy/lonelyలో చూపినట్లుగా ముద్రిస్తుంది. Parent directory నుంచి playbook‌ను అమలు చేయడం సమస్య కాదు. Search మీ shell working directoryని కాకుండా playbook path‌ను అనుసరిస్తుంది. 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‌ను తగ్గిస్తుంది. ఇది meta/main.yml మరియు README stub‌తో సహా పూర్తి skeleton‌ను అందిస్తుంది. ఖాళీగా మిగిలే directories‌ను తొలగించండి. ఖాళీ vars/main.yml role‌లో వాస్తవంగా పనిచేసే files ఏవో గుర్తించడం కష్టతరం చేస్తుంది.