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

Ansible playbook మరియు role: తేడా ఏమిటి

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

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

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

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

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

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

ఈ layout కేవలం style preference కాదు. Ansible ఈ ఖచ్చితమైన pathsలో search చేస్తుంది. అందువల్ల roles/common/template/ (singular) లో ఉంచిన template ఎప్పటికీ కనుగొనబడదు.

ansible-galaxy init తో common role ను రూపొందించండి

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

ఇది మొత్తం skeleton ను roles/common కింద రాస్తుంది. ఇందులో మీరు ఉపయోగించని 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 unquoted 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. Template లో మార్పు జరిగినప్పుడు మాత్రమే తప్పు unit పేరును ఉపయోగించిన handler విఫలమవుతుంది. అందుకే ఈ సమస్య సాధారణంగా కొన్ని వారాల తరువాత బయటపడుతుంది.

ఆ task లో validate line అత్యంత ఉపయోగకరమైనది. Ansible template ను temporary file గా render చేస్తుంది. ఆ file path ను %s స్థానంలో ఉంచి command ను అమలు చేస్తుంది. Command exit 0 ఇచ్చినప్పుడు మాత్రమే destination ను replace చేస్తుంది. Template లో అర్థంలేని directive పెట్టి మళ్లీ run చేయండి. Task failed to validate తో విఫలమవుతుంది, అసలు /etc/ssh/sshd_config.d/99-hardening.conf మారదు, మరియు మీరు ఇంకా login చేయగల server మీ వద్ద ఉంటుంది. ఈ check syntax కంటే ఎక్కువ విషయాలను పరీక్షిస్తుందని గుర్తుంచుకోండి. sshd -t host keys ను చదవలేకపోతే అది sshd: no hostkeys available -- exiting. తో exit అవుతుంది. అప్పుడు Ansible అదే failed to validate ను report చేస్తుంది. కాబట్టి template ను తప్పుపట్టే ముందు module యొక్క msg ను చదవండి.

role ను playbook ఎలా పిలుస్తుంది

# 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 తో ముగియాలి. 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 ఉండవచ్చు. మీరు వాటిని file లో ఏ క్రమంలో రాసినా, 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: ను, include చేసిన role లోని defaults/main.yml scope లోకి రాకముందే evaluate చేస్తారు. include పై when: common_packages | length > 0 రాస్తే, ఆ variable మీరు include చేస్తున్న అదే role లో నిర్వచించబడినప్పటికీ, run 'common_packages' is undefined తో ఆగిపోతుంది. పరిష్కారం toggle ను role బయటకు తరలించడం. దాన్ని group_vars/all.yml లో ఉంచితే అది అన్ని చోట్లా scope లో ఉంటుంది. Role స్వయంగా ఉపయోగించే values కోసం role defaults ను అలాగే ఉంచండి.

ఏ variable కు ప్రాధాన్యం ఉంటుంది: defaults, group_vars, vars, extra vars

Ansible variable precedence కోసం 20 కంటే ఎక్కువ స్థాయిలను documentation లో పేర్కొంటుంది. వాస్తవ వినియోగంలో వచ్చే దాదాపు ప్రతి వివాదాన్ని వాటిలోని నాలుగు స్థాయిలే పరిష్కరిస్తాయి. అవి బలహీనమైనది నుంచి బలమైనది వరకు ఇలా ఉంటాయి.

• roles/<name>/defaults/main.yml దిగువ స్థాయికి సమీపంలో ఉంటుంది. మీరు మరెక్కడైనా సెట్ చేసిన దాదాపు ఏ విలువైనా దీనిని అధిగమిస్తుంది. అందుకే role లో మార్చుకోగల సెట్టింగ్‌లకు ఇది సరైన స్థానం.
• group_vars/ మరియు host_vars/ మధ్యస్థాయిలో ఉంటాయి. మీ site కు సంబంధించిన విలువలు ఇక్కడ ఉండాలి. ఇవి role defaults ను సులభంగా అధిగమిస్తాయి.
• roles/<name>/vars/main.yml, host_vars కంటే పై స్థాయిలో ఉంటుంది. ఇక్కడ సెట్ చేసిన విలువను inventory ద్వారా మార్చలేరు. Role అంతర్గతంగా ఒకే విధంగా ఉండాల్సిన అంశాల కోసం దీన్ని ఉంచాలి. ఉదాహరణకు service name కు సరిపోలాల్సిన package name.
• Call site వద్ద ఇచ్చిన role parameter, vars/main.yml కంటే బలంగా ఉంటుంది. Command line లో ఇచ్చిన -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 దాన్ని మార్చకూడదని తెలియజేస్తారు. కొన్నిసార్లు ఇది ఉద్దేశపూర్వకమే కావచ్చు. అయితే సాధారణంగా ఇది అనుకోకుండా జరిగే పొరపాటు.

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 మధ్య తేడాను గుర్తించలేకపోతున్నాయని అర్థం. అందువల్ల అవి files ను మళ్లీ మళ్లీ రాస్తూ, services ను నిరంతరం restart చేస్తాయి. సాధారణంగా దీనికి command లేదా shell కారణమవుతుంది, ఎందుకంటే యాదృచ్ఛిక 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 ఉంటుంది. రెండో run లో 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 లో కూడా చేయాల్సిన పని దాగి ఉండవచ్చు.

ఆ recap లోని మరో column కు కూడా ఇదే జాగ్రత్త అవసరం: Ansible connect కాలేకపోయిన host ను failed కింద కాకుండా unreachable కింద లెక్కిస్తుంది. ఆ host పై tasks ఏవీ అసలు అమలు కావు. కాబట్టి ఈ role ను రెండు మూడు machines కంటే ఎక్కువకు వర్తింపజేయడానికి ముందు, ఒక unreachable host మొత్తం run ను ఆపాలా వద్దా ముందుగానే నిర్ణయించండి.

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

Ansible ముందుగా playbook ఫైల్ పక్కన ఉన్న roles/ డైరెక్టరీలో, తరువాత roles_path లో role కోసం వెతుకుతుంది. ఈ శోధన మీ shell ను కాకుండా playbook ను అనుసరిస్తుంది.

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

ఈ సందేశం site.yml మరియు roles/ పరస్పరం సరిపోకుండా మారిపోయాయని సూచిస్తుంది. Ansible ప్రయత్నించిన paths ను కూడా చూపిస్తుంది. రెండింటినీ ఒకే directory లో ఉంచండి. Parent directory నుంచి run చేయడం సమస్య కాదు, ఎందుకంటే playbook path నే పరిగణనలోకి తీసుకుంటుంది:

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

ఇదే సమస్యకు తక్కువగా కనిపించే మరో రూపం ఉంది. ప్రస్తుత directory world writable గా ఉన్నప్పుడు Ansible అక్కడి ansible.cfg ను విస్మరిస్తుంది. ఎందుకంటే ఆ machine లోని ఏ user అయినా అక్కడ config ను ఉంచి, మీ run ప్రవర్తనను మార్చవచ్చు.

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

అప్పుడు మీ roles_path మరియు inventory settings నిశ్శబ్దంగా అందుబాటులో లేకుండా పోతాయి. దాంతో roles కు సంబంధం లేని కారణం వల్ల role lookup విఫలమవుతుంది. ansible --version వాస్తవంగా load చేసిన config file ను చూపిస్తుంది. ansible-config dump --only-changed built-in defaults కు భిన్నంగా ఉన్న ప్రతి setting ను చూపిస్తుంది. మీ config ఉన్నట్టుగా run ప్రవర్తించనప్పుడు ఈ రెండింటినీ తనిఖీ చేయండి.

Sharing roles: requirements.yml మరియు నిర్దిష్ట 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 లో ఉన్నదే పొందుతారు. అందువల్ల గత నెలలో పనిచేసిన 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 repository లో commit చేసి review చేయవచ్చు. Third-party roles మాత్రం tag కు pin చేసిన, పునరుత్పత్తి చేయగల downloads గా ఉంటాయి.

పాత్రలు సరైన పరిష్కారం కాని సందర్భాలు

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

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

FAQ

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

అదే tasks బ్లాక్‌ను రెండవ play లో లేదా రెండవ hosts group పై అమలు చేయాల్సి వచ్చినప్పుడు role గా మార్చాలి. Playbooks మధ్య tasks ను copy చేయడం దీనికి సంకేతం. ఆ దశ నుంచి ప్రతి fix ను రెండుసార్లు వర్తింపజేయాలి. ఏదో ఒక రోజు అది ఒక్కసారి మాత్రమే వర్తించే ప్రమాదం ఉంటుంది. సుమారు 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 లో set అయిందా, 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 తో run చేయండి. ఇది ఇతర అన్ని sources కంటే అధిక precedence కలిగి ఉంటుంది.

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

Search playbook file పక్కనుంచి ప్రారంభమవుతుంది. అందువల్ల site.yml మరియు roles/ ఒకే directory లో ఉండాలి. ప్రయత్నించిన paths ను error లో the role 'common' was not found in /home/deploy/lonely/roles:/home/deploy/lonely లా చూపిస్తుంది. Parent directory నుంచి playbook ను run చేయడం సమస్య కాదు. Search మీ shell working directory ను కాకుండా playbook path ను అనుసరిస్తుంది. మీరు ansible.cfg నుంచి roles_path పై ఆధారపడితే, ఆ file ansible --version తో load అయిందో లేదో నిర్ధారించండి. World-writable working directory ఉంటే Ansible దాన్ని ignore చేస్తుంది.

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 ఏవో గుర్తించడం కష్టతరం చేస్తుంది.