Ansible playbook மற்றும் role: எப்போது எதைப்

Ansible playbook மற்றும் role: இவற்றிற்கு இடையேயான வேறுபாடு என்ன

Ansible playbook என்பது நீங்கள் ansible-playbook மூலம் இயக்கும் ஒரு கோப்பாகும். இது ஒரு தொகுப்பு hosts-ஐ, அவை செய்ய வேண்டிய பணிகளுடன் இணைக்கிறது. Ansible role என்பது tasks, templates, handlers மற்றும் default variables ஆகியவற்றை உள்ளடக்கிய ஒரு நிலையான அமைப்பைக் கொண்ட directory ஆகும்; ஒரு playbook அதை அதன் பெயரைக் கொண்டு அழைக்கும். இரண்டிற்குள்ளும் உள்ள task syntax ஒரே மாதிரியானது, எனவே எதைச் செய்ய முடியும் என்பது இங்கு கேள்வியல்ல. இது மறுபயன்பாடு (reuse) குறித்த கேள்வி.

ஒரு எளிய playbook-உடன் தொடங்குங்கள். ஒரு site.yml-ல் உள்ள tasks: பட்டியல் உங்கள் முதல் automation-க்கு சரியான வடிவமாகும், மேலும் இது பெரும்பாலானோர் எதிர்பார்ப்பதை விட நீண்ட காலத்திற்குச் சரியாகவே இருக்கும். அதே பணிகளை மற்றொரு host தொகுப்பிற்கு இயக்க வேண்டியிருக்கும் போதோ, அல்லது கோப்பின் அளவு சுமார் 100 வரிகளைத் தாண்டி, scroll செய்வதன் மூலம் ஒரு task-ஐக் கண்டறிய முடியாத நிலை ஏற்படும் போதோ அதை role-ஆக மாற்றவும்.

நீங்கள் இன்னும் எதையும் எழுதவில்லை என்றால், ஒரு single VPS-க்கு எதிராக முதல் playbook-ஐத் தொடங்குங்கள் மற்றும் அது வளரத் தொடங்கும் போது மீண்டும் வாருங்கள்.

எப்போது ஒரு flat playbook சரியான தீர்வாகிறது

வேலை ஒருமுறை மட்டுமே நடக்கும்போது, அல்லது ஒரே ஒரு host-ல் மட்டும் நடக்கும்போது, அல்லது வேறு யாரும் அதைப் படிக்கப்போவதில்லை என்ற சூழலில் ஒரு flat playbook சரியான தேர்வாகும். ஒரு application server-ஐ provision செய்யும்போதோ அல்லது maintenance window-க்கு முன்னதாக ஒரு server-ஐ patch செய்யும்போதோ, அவற்றுக்கு ஒரு directory tree தேவையில்லை. ஒரு role-ஐ உருவாக்கும்போது ஏழு directories மற்றும் ஒரு கூடுதல் மறைமுக அடுக்கு (layer of indirection) உருவாகிறது. அந்த role-ஐ அழைக்கும் ஒரே playbook அதன் அருகிலேயே இருந்தால், அந்த மறைமுக அடுக்கு எந்தப் பயனும் தராது; மாறாக, உண்மையில் என்ன இயங்குகிறது என்பதைப் பார்க்க ஒவ்வொரு முறையும் நீங்கள் ஒரு கோப்பிற்குத் தாவ வேண்டியிருக்கும்.

ஒரு குறிப்பிட்ட தருணத்தில் flat playbook-ன் பயன்பாடு முடிவுக்கு வருகிறது, அந்தத் தருணத்தைக் கண்டறிவது எளிது. நீங்கள் ஒரு task தொகுப்பை நகலெடுத்து இரண்டாவது playbook-ல் சேர்க்கும்போது, அதுவே அதற்கான அறிகுறியாகும். அதன் பிறகு ஒவ்வொரு திருத்தத்தையும் நீங்கள் இரண்டு முறை செய்ய வேண்டியிருக்கும், ஏதோ ஒரு நாளில் நீங்கள் அதை ஒருமுறை மட்டுமே செய்வீர்கள்.

ஒரு 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 என்பது தொடக்கப் புள்ளியாகும். ஒரு role அழைக்கப்படும்போது Ansible இந்த கோப்பை இயக்குகிறது, மற்ற அனைத்து directory-களும் விருப்பத்திற்குரியவை.
• defaults/main.yml என்பது அழைப்பவர் மாற்றியமைக்க வேண்டிய மாறிகளை (variables) கொண்டுள்ளது. Ansible-ல் இதுவே மிகக் குறைந்த முன்னுரிமை கொண்ட ஆதாரமாகும், எனவே மற்ற அனைத்தும் இதைவிட அதிக முன்னுரிமை பெறும்.
• vars/main.yml என்பது அழைப்பவர் மாற்றியமைக்கக் கூடாத மாறிகளைக் கொண்டுள்ளது. இது முன்னுரிமை வரிசையில் inventory-க்கு மேலே உள்ளது, இது மிக முக்கியமான ஒன்றாகும். இதை அரிதாகவே பயன்படுத்தவும்.
• handlers/main.yml என்பது notify மூலம் தூண்டப்படும் பணிகளைக் (tasks) கொண்டுள்ளது. ஒரு handler, எத்தனை பணிகள் அதை அழைத்தாலும், play-ன் இறுதியில் ஒருமுறை மட்டுமே இயங்கும்.
• files/ என்பது copy module மூலம் அப்படியே நகலெடுக்கப்படும் கோப்புகளைக் கொண்டுள்ளது, மற்றும் templates/ என்பது template module மூலம் உருவாக்கப்படும் Jinja2 templates-களைக் கொண்டுள்ளது. ஒரு role-க்குள், நீங்கள் இரண்டையும் பாதை குறிப்பிடாமல் கோப்பின் பெயரை மட்டும் கொண்டு குறிப்பிடலாம், ஏனெனில் Ansible முதலில் அந்த role-ன் சொந்த directory-களில் தேடும்.
• meta/main.yml என்பது role சார்ந்த சார்புகளை (dependencies) மற்றும் Ansible Galaxy வாசிக்கும் metadata-வை அறிவிக்கிறது.

இந்த அமைப்பு ஒரு விருப்பத்தேர்வு அல்ல. Ansible இந்த குறிப்பிட்ட பாதைகளில் மட்டுமே தேடுகிறது, எனவே நீங்கள் roles/common/template/ (ஒருமையில்) என்று வைக்கும் template ஒருபோதும் கண்டறியப்படாது.

ansible-galaxy init மூலம் பொதுவான role-ஐ உருவாக்குதல்

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

இது roles/common-ன் கீழ் முழுமையான கட்டமைப்பு கோப்புகளை உருவாக்குகிறது. இதில் நீங்கள் பயன்படுத்தாத directories மற்றும் --- மட்டுமே கொண்ட main.yml stubs-களும் அடங்கும். நீங்கள் பயன்படுத்தாத கோப்புகளை நீக்கிவிடவும். காலியான vars/main.yml Ansible-க்கு எந்த பாதிப்பையும் ஏற்படுத்தாது, ஆனால் எந்தெந்த கோப்புகள் உண்மையில் பயன்பாட்டில் உள்ளன என்பதைப் புரிந்துகொள்வதை இது கடினமாக்கும்.

இப்போது செயல்பாட்டிற்குத் தேவையான கோப்புகளை நிரப்பவும். முதலில் 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 மூலம் பகுப்பாய்வு செய்கிறது. இது வெறும் no என்பதை boolean false ஆகக் கருதும். இதனால் உருவாக்கப்படும் config வரியானது PermitRootLogin False என மாறிவிடும், இதை sshd நிராகரித்துவிடும். மேற்கோள் குறிகள் இந்த மதிப்பை 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 குடும்பத்தைச் சேர்ந்த கணினிகளில் இது sshd ஆகும். தவறான பெயரைக்கொண்ட handler, template-ல் மாற்றம் ஏற்படும்போது மட்டுமே தோல்வியடையும். இதனால்தான் இத்தகைய பிழைகள் பல வாரங்களுக்குப் பிறகே வெளிச்சத்திற்கு வருகின்றன.

அந்த task-ல் validate வரி மிகவும் பயனுள்ளது. Ansible, template-ஐ ஒரு தற்காலிகக் கோப்பாக உருவாக்கி, அந்தப் பாதையை %s-க்கு மாற்றீடு செய்து, கட்டளையை இயக்குகிறது. கட்டளை 0 என்ற exit code-ஐ வழங்கினால் மட்டுமே இலக்குக் கோப்பு மாற்றப்படும். template-ல் ஒரு தவறான directive-ஐ இட்டு மீண்டும் இயக்கவும்: task failed to validate பிழையுடன் தோல்வியடையும், உண்மையான /etc/ssh/sshd_config.d/99-hardening.conf மாறாமல் இருக்கும், மேலும் உங்களால் தொடர்ந்து server-க்குள் நுழைய முடியும். இந்தச் சோதனை உங்கள் syntax-ஐ மட்டும் சரிபார்ப்பதில்லை என்பதை நினைவில் கொள்க. sshd -t-ஆல் host keys-ஐ வாசிக்க முடியவில்லை என்றால், அது sshd: no hostkeys available -- exiting.-ஐத் தரும். Ansible-ம் அதே failed to validate பிழையைத்தான் காட்டும். எனவே, template-ஐக் குறை கூறுவதற்கு முன் அந்த module-ன் msg-ஐ வாசிக்கவும்.

ஒரு playbook ஒரு 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

Play-ன் இறுதியில் recap-ல் failed=0 இருக்க வேண்டும். விரிவுபடுத்தப்பட்ட வடிவத்தைப் பயன்படுத்தி அழைக்கும் இடத்தில் parameters-ஐ அனுப்பவும்; இதன் மூலமே ஒரு role இரண்டு வெவ்வேறு host குழுக்களுக்குப் பயன்படுகிறது:

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

எல்லோரையும் ஆச்சரியப்படுத்தும் ஒரு வரிசைமுறை விதி உள்ளது. ஒரு play-ல் pre_tasks, roles, tasks மற்றும் post_tasks இருக்கலாம்; நீங்கள் கோப்பில் எந்த வரிசையில் எழுதினாலும், Ansible அவற்றை இந்த வரிசையிலேயே இயக்கும். 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 செய்யும் நேரத்திலேயே role-ஐ வாசித்து அதன் tasks-ஐ play-ன் ஒரு பகுதியாக மாற்றுகிறது; எனவே ansible-playbook --list-tasks site.yml அவற்றை பட்டியலிடும், மேலும் import-ல் உள்ள ஒரு tag அந்த role-க்குள் உள்ள அனைத்து tasks-க்கும் பொருந்தும். include_role என்பது dynamic ஆகும். அந்த task இயங்கும் வரை எதுவும் வாசிக்கப்படாது; இதனால்தான் ஒரு variable அல்லது loop மூலம் role-ன் பெயரைத் தீர்மானிக்க முடிகிறது. இதன் குறைபாடு என்னவென்றால், அந்த tasks --list-tasks மற்றும் --start-at-task-க்குத் தெரியாது.

இதில் ஒரு சிக்கல் உள்ளது. ஒரு include_role task-ல் உள்ள when:, அந்த role-ன் defaults/main.yml scope-க்குள் வருவதற்கு முன்பே மதிப்பீடு செய்யப்படுகிறது. include-ல் when: common_packages | length > 0-ஐ எழுதினால், நீங்கள் include செய்யும் role-லேயே அந்த variable வரையறுக்கப்பட்டிருந்தாலும், 'common_packages' is undefined பிழையுடன் இயக்கம் நின்றுவிடும். இதைச் சரிசெய்ய, அந்த toggle-ஐ role-லிருந்து வெளியே எடுக்க வேண்டும்: அதை group_vars/all.yml-ல் வைக்கவும், அங்கு அது எல்லா இடங்களிலும் scope-ல் இருக்கும்; role-ன் defaults-ஐ அந்த role பயன்படுத்தும் மதிப்புகளுக்கு மட்டும் விட்டுவிடவும்.

எந்த variable முன்னுரிமை பெறும்: defaults, group_vars, vars, extra vars

Ansible-ல் இருபதுக்கும் மேற்பட்ட variable முன்னுரிமை நிலைகள் உள்ளன. அவற்றில் நான்கு நிலைகள் பெரும்பாலான நடைமுறைச் சிக்கல்களைத் தீர்க்கின்றன. வலிமை குறைந்த நிலையிலிருந்து வலிமை மிகுந்த நிலையை வரிசைப்படுத்தினால்:

• roles/<name>/defaults/main.yml வரிசையின் கீழ் நிலையில் உள்ளது. நீங்கள் வேறு எங்கு அமைக்கும் மதிப்பும் இதை விட அதிக முன்னுரிமை பெறும். எனவே, ஒரு role-ன் மாற்றியமைக்கக்கூடிய அமைப்புகளை (tunable knobs) இங்கு வைப்பதே சரியானது.
• group_vars/ மற்றும் host_vars/ ஆகியவை இடைப்பட்ட நிலையில் உள்ளன. உங்கள் தளத்திற்குரிய குறிப்பிட்ட மதிப்புகளை இங்கு அமைக்க வேண்டும்; இவை role defaults-ஐ எளிதாக மாற்றியமைக்கும் (override).
• roles/<name>/vars/main.yml ஆனது host_vars-க்கு மேல் உள்ளது. இங்கு நீங்கள் அமைக்கும் மதிப்பை inventory மூலம் மாற்ற முடியாது. ஒரு role-ன் உள்ளமைவு சீராக இருக்கத் தேவையான விஷயங்களுக்கு (உதாரணமாக, service பெயருடன் பொருந்த வேண்டிய package பெயர்) இதை ஒதுக்குங்கள்.
• ஒரு role-ஐ அழைக்கும் இடத்தில் (call site) வழங்கப்படும் 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

முதல் முறை இயக்கும்போது tunable=from-hostvars internal=from-rolevars அச்சிடப்படும். Inventory-ல் உள்ள மதிப்பு role default-ஐ விட அதிக முன்னுரிமை பெற்று, role var-ஐ விடக் குறைந்த முன்னுரிமை பெற்றுள்ளது. இரண்டாவது முறை இயக்கும்போது internal=from-cli அச்சிடப்படும், ஏனெனில் extra vars மிக உயர்ந்த நிலையில் உள்ளது; இதை எவராலும் மாற்ற முடியாது. இதனால்தான் -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-ம் தற்போதைய நிலையை ஆய்வு செய்து, வேலை ஏற்கனவே முடிந்துவிட்டதை உறுதிப்படுத்தியதைக் குறிக்கிறது. இரண்டாவது முறை இயக்கும்போது changed=2 என்று வந்தால், அந்த இரண்டு task-களும் மாற்றத்தை உணரவில்லை என்று அர்த்தம்; இதனால் அவை தொடர்ந்து கோப்புகளை மீண்டும் எழுதி, service-களை restart செய்துகொண்டே இருக்கும். இதற்கு பெரும்பாலும் 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 இடம்பெற்றுள்ள வரிகளை எண்ணவும். /tmp/grow.txt இரண்டு வரிகளைக் கொண்டிருக்கும், /tmp/guarded.txt ஒரு வரியைக் கொண்டிருக்கும். இரண்டாவது முறை இயக்கும்போது, பாதுகாக்கப்பட்ட task (guarded task) இயங்காது. அதன் முடிவு skipped, since /tmp/guarded.txt exists என்ற செய்தியைக் கொண்டிருக்கும், ஏனெனில் creates அந்த module-க்கு முதலில் தேட வேண்டிய ஒரு பொருளை (product) வழங்குகிறது. ஒரு கட்டளை அத்தகைய பொருளை உருவாக்கவில்லை என்றால், அதன் output-ஐ register செய்து, changed_when மூலம் நீங்களே முடிவெடுக்கவும்.

ansible-playbook --check --diff site.yml மாற்றங்களைச் செய்யாமலேயே அவற்றை முன்கூட்டியே கணிக்கும், --diff ஒரு template எதை மாற்றப்போகிறது என்பதைத் துல்லியமாகக் காட்டும். இந்த output-ஐப் பார்க்கும்போது ஒரு எச்சரிக்கையை மனதில் கொள்ளவும்: shell மற்றும் command task-கள் check mode-ல் தவிர்க்கப்படும். எனவே, பார்ப்பதற்குச் சரியாகத் தெரியும் ஒரு திட்டம், சில வேலைகளை மறைத்து வைத்திருக்கக்கூடும்.

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/ ஆகியவை ஒன்றையொன்று விட்டு விலகிவிட்டன என்பதைக் குறிக்கிறது; அது தேடிய பாதைகளை அதுவே அச்சிட்டுக் காட்டும். இரண்டையும் ஒரே கோப்பகத்தில் வைத்திருங்கள். ஒரு parent directory-லிருந்து இயக்குவது தவறல்ல, ஏனெனில் playbook-ன் பாதையே கணக்கில் கொள்ளப்படும்:

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

இதே சிக்கலில் அமைதியான ஒரு பதிப்பும் உள்ளது. தற்போதைய கோப்பகம் world writable ஆக இருந்தால், Ansible அங்கிருக்கும் ansible.cfg-ஐப் புறக்கணிக்கும். ஏனெனில், அந்த server-ல் உள்ள எந்தவொரு பயனரும் அங்கு ஒரு config கோப்பை வைத்து உங்கள் செயல்பாட்டை மாற்ற முடியும்.

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

அப்போது உங்கள் roles_path மற்றும் inventory அமைப்புகள் அமைதியாக விடுபட்டுவிடும், மேலும் role-களைத் தேடும் செயல்பாடு தோல்வியடையும். இது role-களுடன் தொடர்பில்லாத ஒரு காரணமாகும். ansible --version அது உண்மையில் ஏற்றிய config file-ஐ அச்சிடும், மேலும் ansible-config dump --only-changed இயல்புநிலை அமைப்புகளிலிருந்து மாறுபடும் ஒவ்வொரு அமைப்பையும் அச்சிடும். உங்கள் config கோப்பு இல்லையென்பது போல ஒரு run செயல்படும்போது, இவை இரண்டையும் சரிபார்க்கவும்.

பங்களிப்பு பாத்திரங்கள் (Roles): requirements.yml மற்றும் pinned version

மற்றொருவர் எழுதிய ஒரு role-ஐ நகலெடுக்காமல், install செய்ய வேண்டும். அதை ஒருமுறை மட்டும் கீழே உள்ளவாறு குறிப்பிடவும்:

# 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-ஐ அமைக்கவும். இதைச் செய்யாவிட்டால், நீங்கள் கட்டளையை இயக்கும் நாளில் 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-உடன் சேர்த்து அந்தப் பாதையும் எப்போதும் தேடப்படும். எனவே, உங்கள் சொந்த roles-ஐ commit செய்து ஆய்வு செய்ய முடியும், அதே சமயம் மூன்றாம் தரப்பு roles-ஐ ஒரு குறிப்பிட்ட tag-ல் நிலைநிறுத்தி (pinned) மீண்டும் உருவாக்கக்கூடிய வகையில் பதிவிறக்கம் செய்துகொள்ளலாம்.

Roles தீர்வாக இல்லாத சூழல்கள்

ஒரு role என்பது ஒரு Ansible run-க்குள் மறுபயன்பாட்டிற்கான ஒரு அலகு ஆகும். இது உங்கள் service provider-ல் servers-ஐ உருவாக்கவோ அல்லது DNS records-ஐ அமைக்கவோ செய்யாது. அவ்வாறு செய்ய முயற்சிப்பது, பராமரிக்க முடியாத சிக்கலான playbooks-ஐ உருவாக்கும். நீங்கள் தொடங்குவதற்கு முன் Ansible மற்றும் Terraform இடையிலான பணிப்பிரிப்பு குறித்த கட்டுரையை வாசிப்பது அவசியம். ஒரு role என்பது inventory வடிவமைப்பிற்கு மாற்றாகாது: சில servers-ஐத் தாண்டியவுடன், servers-ஐ எவ்வாறு குழுப்படுத்துவது மற்றும் அணுகுவது என்பது tasks எவ்வாறு கோப்பு செய்யப்பட்டுள்ளன என்பதை விட முக்கியமானது.

இந்த common role நிறுவும் hardening அமைப்புகளுக்கும் தனிப்பட்ட முடிவுகள் தேவை. மேலே உள்ள drop-in இரண்டு directives-ஐ மட்டுமே அமைக்கிறது. எனவே, நீங்கள் வைத்திருக்கும் ஒவ்வொரு host-க்கும் எவை தேவை என்பதை முடிவு செய்வதற்கு முன், எந்த SSH அமைப்புகளை மாற்றுவது பயனுள்ளது மற்றும் Ubuntu-வில் தானாகவே security updates-ஐ எவ்வாறு செயல்படுத்துவது என்பதைப் படிக்கவும்.

FAQ

Ansible playbook-ஐ எப்போது role-ஆக மாற்ற வேண்டும்?

ஒரே தொகுப்பு பணிகளை (tasks) இரண்டாவது play-ல் அல்லது இரண்டாவது host குழுவில் இயக்க வேண்டியிருக்கும் போது மாற்ற வேண்டும். Playbook-களுக்கு இடையே பணிகளை நகலெடுப்பது ஒரு எச்சரிக்கை அறிகுறியாகும்; ஏனெனில், ஒரு திருத்தத்தை இருமுறை செய்ய வேண்டிய சூழலில், ஏதேனும் ஒருமுறை தவறு நடக்க வாய்ப்புள்ளது. சுமார் 100 வரிகளுக்குக் குறைவாகவும், ஒரே ஒரு குழுவை மட்டும் இலக்காகக் கொண்ட playbook-க்கு role-ஆல் எந்தப் பயனும் இல்லை; மாறாக, கூடுதல் directories கோப்புகளைப் படிப்பதை கடினமாக்கும்.

ஒரே play-ல் உள்ள tasks-க்கு முன்பாக roles இயங்குமா?

ஆம். Ansible முதலில் pre_tasks-ஐ இயக்கும், பிறகு roles:-ன் கீழ் உள்ள அனைத்தையும், அடுத்து tasks:, இறுதியில் post_tasks:-ஐ இயக்கும். உங்கள் கோப்பில் இந்த keys எந்த வரிசையில் இருந்தாலும், Ansible அதன் சொந்த வரிசையிலேயே இயக்கும். tasks:-ஐ roles:-க்கு மேலே எழுதினாலும், அவை முதலில் இயங்காது. ஒரு பணி role-க்கு முன்பாக நடக்க வேண்டும் என்றால், அதை pre_tasks:-ல் சேர்க்கவும்.

எனது group_vars மதிப்பு ஏன் role-ஐ override செய்யவில்லை?

அந்த variable, defaults/main.yml-க்கு பதிலாக role-ன் vars/main.yml-ல் அமைக்கப்பட்டுள்ளதா என்று சரிபார்க்கவும். Ansible-ன் முன்னுரிமை வரிசையில் (precedence order) vars/ என்பது group_vars மற்றும் host_vars-க்கு மேலாக இருப்பதால், inventory-ஆல் அதை override செய்ய முடியாது. அந்த variable-ஐ defaults/main.yml-க்கு மாற்றவும்; இது வரிசையின் இறுதியில் இருப்பதால், caller மாற்ற விரும்பும் எதற்கும் இதுவே சரியான இடமாகும். இது எழுத்துப் பிழையா அல்லது முன்னுரிமைப் பிரச்சினையா என்பதை உறுதிப்படுத்த, அனைத்து ஆதாரங்களையும் விட அதிக முன்னுரிமை கொண்ட -e name=value-ஐப் பயன்படுத்தி ஒருமுறை இயக்கவும்.

Ansible ஏன் role-ஐக் கண்டறிய முடியவில்லை என்று கூறுகிறது?

தேடல் playbook கோப்பிற்கு அருகிலேயே தொடங்கும், எனவே site.yml மற்றும் roles/ ஒரே directory-ல் இருக்க வேண்டும். பிழைச் செய்தி, the role 'common' was not found in /home/deploy/lonely/roles:/home/deploy/lonely-ல் உள்ளதைப் போல அது தேடிய பாதைகளைக் காட்டும். Playbook-ஐ ஒரு parent directory-லிருந்து இயக்குவது சரிதான், ஏனெனில் தேடல் உங்கள் shell-ன் working directory-ஐப் பின்பற்றாமல், playbook-ன் பாதையைப் பின்பற்றும். நீங்கள் ansible.cfg-லிருந்து roles_path-ஐச் சார்ந்திருந்தால், அந்த கோப்பு ansible --version மூலம் ஏற்றப்பட்டதா என்பதை உறுதிப்படுத்தவும்; ஏனெனில், எவரும் எழுதக்கூடிய (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 தட்டச்சு செய்வதைக் குறைத்து, meta/main.yml மற்றும் README stub உள்ளிட்ட முழுமையான கட்டமைப்பை வழங்குகிறது. நீங்கள் பயன்படுத்தாத directories-ஐ நீக்கிவிடவும், ஏனெனில் காலியாக உள்ள vars/main.yml, role-ல் எந்தெந்த கோப்புகள் உண்மையில் செயல்படுகின்றன என்பதை மறைத்துவிடும்.