ஆல் Matt Connor 2026-07-16 · புதுப்பிக்கப்பட்டது 2026-08-07

Ubuntu 24.04-ல் Ansible Playbook உருவாக்குவது எப்படி?

Q: Ansible ஏன் "Permission denied (publickey)" என்று காட்டுகிறது?

UNREACHABLE! மற்றும் Permission denied (publickey) கொண்ட block, Ansible எதையும் இயக்கும் முன்பே SSH authentication தோல்வியடைந்ததைக் குறிக்கிறது. inventory-ல் உள்ள ansible_user, நீங்கள் உருவாக்கிய account-உடன் ஒத்துப்போகிறதா என்பதையும், அந்த host-க்கு ssh-copy-id செய்துள்ளீர்களா என்பதையும், கடவுச்சொல் இன்றி ssh user@host மூலம் login செய்ய முடிகிறதா என்பதையும் சரிபார்க்கவும். plain ssh command-ஐச் சரிசெய்யும் எந்தவொரு நடவடிக்கையும் Ansible-ஐயும் சரிசெய்யும், ஏனெனில் இவை இரண்டும் ஒரே transport-ஐப் பயன்படுத்துகின்றன.

Q: ansible மற்றும் ansible-core packages-க்கு என்ன வித்தியாசம்?

ansible-core என்பது engine மற்றும் அதனுடன் சில ansible.builtin modules-ஐ மட்டுமே கொண்டது. ansible package, core-உடன் சேர்த்து சமூகத்தால் தேர்ந்தெடுக்கப்பட்ட collections-ஐயும் கொண்டுள்ளது. இதில் இந்த வழிகாட்டியில் பயன்படுத்தப்படும் ansible.posix (authorized_key module) மற்றும் community.general (ufw module) ஆகியவையும் அடங்கும். முழுமையான package-உடன் தொடங்கவும்; தேவைப்படும்போது மட்டும் core மற்றும் குறிப்பிட்ட collections-க்கு மாறவும்.

Ubuntu 24.04-ல் pipx மூலம் Ansible நிறுவுவது, inventory அமைப்பது மற்றும் VPS பாதுகாப்புக்கான முதல் playbook எழுதுவது எப்படி என்பதை அறியுங்கள். Permission denied பிழைகளைத் தவிர்க்கவும்.

நீங்கள் உருவாக்குவது

Ansible நிறுவப்பட்ட ஒரு control machine மற்றும், stock image தவிர வேறெதுவும் இல்லாத ஒன்று அல்லது அதற்கு மேற்பட்ட புதிய Ubuntu 24.04 VPS-கள் உங்களிடம் இருக்கும். இறுதியில், உங்கள் server-களைக் குறிப்பிடும் ஒரு inventory file, authentication சரியாக வேலை செய்கிறது என்பதை உறுதிப்படுத்தும் ad-hoc ping, மற்றும் புதிய VPS-க்கான முழு checklist-ஐயும் code-ஆக இயக்கும் ஒரு playbook ஆகியவற்றை நீங்கள் பெற்றிருப்பீர்கள்: உங்கள் SSH key-உடன் கூடிய deploy user, hardened sshd, fail2ban, unattended upgrades, மற்றும் அனைத்தையும் தடுப்பதற்கு முன் OpenSSH-ஐ அனுமதிக்கும் firewall. இதை ஒரு server-க்கோ அல்லது இருபது server-களுக்கோ பயன்படுத்தலாம். இதை இரண்டு முறை இயக்கினாலும், இரண்டாவது முறை எந்த மாற்றமும் செய்யாது; அதுவே இதன் முக்கிய நோக்கமாகும்.

பதினைந்து ஆண்டுகளாக VPS-களை provisioning செய்த அனுபவத்தில், உண்மையான நடைமுறையை என்னால் கூற முடியும்: அனைவரும் முதல் ஐந்து server-களை கையால் (manually) அமைப்பார்கள், ஆறாவது server-ன் போது ஒரு வார இறுதியை இழப்பார்கள், ஏனெனில் முதல் ஐந்து server-களில் என்ன செய்தோம் என்பது யாருக்கும் நினைவிருக்காது. இந்த வழிகாட்டி பல Linux server-களை நிர்வகித்தல் குறித்த ஆய்வை ஆழப்படுத்துகிறது; நீங்கள் ஒரே apt install-ஐ மூன்று terminal-களில் தட்டச்சு செய்வதைக் கவனிக்கும் நாளில் இதைப் பயன்படுத்தத் தொடங்குங்கள்.

Ansible என்றால் என்ன என்பதற்கான சுருக்கமான விளக்கம்

Ansible ஒரு agentless கருவியாகும். இது நிர்வகிக்கும் server-களில் எந்தவொரு daemon-ஐயும் நிறுவ வேண்டியதில்லை: control machine சாதாரண SSH மூலம் இணைப்பை ஏற்படுத்தி, ஒரு சிறிய Python module-ஐ target-க்கு நகர்த்தி, அதை இயக்கி, அது வெளியிடும் JSON-ஐ வாசித்து, பின்னர் அதை நீக்கிவிடும். target-க்குத் தேவையானது python3 மட்டுமே, இது ஏற்கனவே அனைத்து standard Ubuntu image-களிலும் உள்ளது. இதில் கவனிக்க வேண்டிய முக்கியமான சொல் idempotent ஆகும்; இதன் பொருள் எளிமையானது: ஒரு task என்பது ஒரு செயலை அல்ல, ஒரு நிலையை (state) விவரிக்கிறது. ஒரு package-க்கான state: present என்பது "installer-ஐ இயக்கு" என்று அர்த்தமல்ல, மாறாக "இது நிறுவப்பட்டிருப்பதை உறுதி செய்" என்று அர்த்தம். அந்த நிலை ஏற்கனவே இருந்தால், Ansible எதையும் மாற்றாது மற்றும் அதை changed என்பதற்குப் பதிலாக ok என்று தெரிவிக்கும். இந்தத் தன்மையே இந்தத் தயாரிப்பின் முழுமையான சாராம்சம்; இதுவே playbook-ஐ மீண்டும் இயக்குவதைப் பாதுகாப்பானதாக்குகிறது. இத்தகைய பாதுகாப்பான மறுஇயக்கங்களே ஒரு shell script-ஐ infrastructure-ஆக மாற்றுகின்றன.

முன்நிபந்தனைகள் மற்றும் கவனிக்க வேண்டியவை

ஒரு கட்டுப்பாட்டு இயந்திரம் (control machine): உங்கள் மடிக்கணினி அல்லது ஒரு சிறிய VPS. நான் Ubuntu 24.04-ஐ பயன்படுத்துவதாகக் கொள்கிறேன்; Homebrew மூலம் pipx நிறுவப்பட்டால் macOS-லும் இது போலவே செயல்படும்.
ஒன்று அல்லது அதற்கு மேற்பட்ட இலக்கு VPS-கள்: இவை KVM-ல் Ubuntu 24.04 இயங்க வேண்டும் மற்றும் root பயனர் மூலம் அணுகக்கூடியதாக இருக்க வேண்டும். இவற்றில் எதையும் நிறுவ வேண்டியதில்லை.
ஒவ்வொரு இலக்கிற்கும் SSH key அங்கீகாரம்: உங்கள் ssh கட்டளைக்கு என்ன அங்கீகாரம் உள்ளதோ, அதே அங்கீகாரம் தான் Ansible-க்கும் உண்டு. ssh root@host கடவுச்சொல்லைக் கேட்டால், Ansible தோல்வியடையும்.
Ubuntu 24.04-ல், pip install ansible கட்டளை error: externally-managed-environment பிழையுடன் நின்றுவிடும். இது விநியோகத்தின் (distro) திட்டமிட்ட கொள்கையே தவிர, மென்பொருள் பழுது அல்ல. pipx-ஐப் பயன்படுத்தவும்.
YAML-ல் இடைவெளி (whitespace) என்பது ஒரு syntax ஆகும். தவறான indent mapping values are not allowed in this context பிழையை உருவாக்கும், மேலும் tab எழுத்து எங்கு இருந்தாலும் அது பிழையை ஏற்படுத்தும்.
sshd-ஐ பலப்படுத்தும் (harden) playbook-ஐ இயக்கும்போது, ஒவ்வொரு இலக்கிலும் ஒரு SSH session-ஐத் திறந்து வைத்திருக்கவும். வாடிக்கையாளர்கள் தங்களை தாங்களே பூட்டிக்கொண்ட (lockout) அனைத்துச் சம்பவங்களிலும், "புதிதாகச் சோதிக்க" என்று கடைசி session-ஐ மூடியதே காரணமாக இருந்தது.

படி 1: control machine-ல் pip-க்கு பதிலாக pipx கொண்டு Ansible-ஐ நிறுவுதல்

வழக்கமான அணுகுமுறை pip3 install ansible ஆகும். புதிய 24.04 image-ல் இது ஒரு கட்டத்திலேயே தோல்வியடையும், Command 'pip3' not found, but can be installed with: sudo apt install python3-pip, மேலும் pip-ஐ மட்டும் நிறுவுவது உங்களை உண்மையான சிக்கலுக்கு இட்டுச் செல்லும்:

pip3 install ansible

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

Ubuntu 24.04-ல் system Python ஆனது externally managed (PEP 668) என குறிக்கப்பட்டுள்ளது, எனவே ஒரே கோப்புகளுக்காக pip மற்றும் apt மோதிக்கொள்ள முடியாது. --break-system-packages-ஐ பயன்படுத்த வேண்டாம்; அந்த flag-ன் பெயரே அதன் நோக்கத்தை தெளிவாகக் கூறுகிறது. இதற்கான சரியான தீர்வு pipx ஆகும், இது Ansible-க்கு தனித்துவமான virtualenv-ஐ உருவாக்கி, அதன் binaries-ஐ உங்கள் PATH-ல் சேர்க்கிறது:

sudo apt update && sudo apt install -y pipx
pipx ensurepath
pipx install --include-deps ansible

pipx ensurepath-க்கு பிறகு புதிய shell-ஐத் திறக்கவும், அப்போதுதான் PATH மாற்றம் அமலுக்கு வரும். --include-deps என்பது அலங்காரத்திற்காக அல்ல: ansible தொகுப்பில் சொந்தமாக console scripts இல்லை, ansible, ansible-playbook மற்றும் பிற அனைத்தும் அதன் ansible-core dependency-ன் entry points ஆகும், எனவே அந்த flag இல்லையெனில் pipx நிறுவுதலை மறுத்து No apps associated with package ansible or its dependencies பிழையைக் காட்டும். மேலும், வெறும் ansible-core-ஐ நிறுவ வேண்டாம், ansible தொகுப்பையே நிறுவவும்; முழுமையான தொகுப்பு community collections-ஐ உள்ளடக்கியது, இந்த playbook அவற்றில் இரண்டைப் (ansible.posix மற்றும் community.general) பயன்படுத்துகிறது.

ansible --version

சரியான நிறுவல் ansible [core 2.19.x] போன்ற வரியுடன் தொடங்கும் மற்றும் அது இயங்கும் Python-ன் பெயரைக் காட்டும்; தற்போதைய core release எதுவாக இருந்தாலும் இந்த tutorial-க்கு போதுமானது. ansible: command not found என்று வந்தால், ~/.local/bin இன்னும் உங்கள் PATH-ல் இல்லை, புதிய shell-ஐத் திறக்கவில்லை அல்லது source ~/.bashrc என்று அர்த்தம்.

நிறுவல் இவ்வளவுதான். இலக்கு இயந்திரங்களில் (targets) எதையும் நிறுவ வேண்டியதில்லை.

படி 2: ஒவ்வொரு target-க்கும் SSH key access

ssh-keygen -t ed25519 -C "ansible control"
ssh-copy-id root@10.0.0.10
ssh-copy-id root@10.0.0.20

பின்பு, ஒவ்வொரு host-க்கும் ஒருமுறை இதைச் சரிபார்க்கவும்:

ssh root@10.0.0.10 true && echo ok

இந்த ஒரே வரி இரண்டு பணிகளைச் செய்கிறது: இது கடவுச்சொல் (password) இன்றி key authentication சரியாக வேலை செய்வதை உறுதிப்படுத்துகிறது, மேலும் host key-ஐ known_hosts-ல் பதிவு செய்கிறது. இதை இப்போதே செய்யவும், ஏனெனில் Ansible-ல் பதிவு செய்யப்படாத host key ஒரு interactive prompt-ஆகத் தோன்றும். இது run-ன் இடையில் வருவதால், ஏதோ process நின்றுவிட்டது (hang) போன்ற தோற்றத்தை உருவாக்கும்.

படி 3: inventory, முதலில் INI, வளர்ந்த பிறகு YAML

Inventory என்பது Ansible கையாளக்கூடிய கணினிகளின் பட்டியலைக் கொண்ட ஒரு உரைக்கோப்பு (text file) ஆகும். ஒரு புதிய project directory-ல் inventory.ini-ஐ உருவாக்கவும்:

[vps]
web1 ansible_host=10.0.0.10
web2 ansible_host=10.0.0.20

[vps:vars]
ansible_user=root

web1 என்பது நீங்கள் தேர்ந்தெடுக்கும் ஒரு alias; இதுவே output-ல் தோன்றும் மற்றும் --limit web1 மூலம் நீங்கள் இலக்கு வைக்கும் பெயராகவும் இருக்கும். ansible_host என்பது உண்மையான முகவரி. [vps] என்பது ஒரு group, மற்றும் [vps:vars] என்பது அதில் உள்ள அனைத்து host-களுக்கும் மாறிகளை (variables) அமைக்கும்; ansible_user என்பது Ansible எந்தப் பயனராக login செய்யும் என்பதைக் குறிக்கும். அதன் அருகில் ஒரு ansible.cfg-ஐச் சேர்க்கவும், அப்போதுதான் நீங்கள் மீண்டும் -i-ஐத் தட்டச்சு செய்ய வேண்டியிருக்காது:

[defaults]
inventory = inventory.ini

Ansible தற்போதைய directory-லிருந்து ansible.cfg-ஐ வாசிக்கும். அதே inventory-ஐ YAML வடிவில், inventory.yml எனச் சேமித்து, ansible.cfg-ஐ அந்தப் பெயருக்குச் சுட்டிக்காட்டுவது, host-கள் ஒவ்வொன்றிலும் பல மாறிகளைக் கொண்டிருக்கும்போது உங்களுக்குச் சிறந்ததாக இருக்கும்:

vps:
  hosts:
    web1:
      ansible_host: 10.0.0.10
    web2:
      ansible_host: 10.0.0.20
  vars:
    ansible_user: root

இவை இரண்டும் சமமானவை. இரண்டு server-கள் இருக்கும்போது INI-ஐப் பார்ப்பது எளிது; இருபது server-கள் இருக்கும்போது YAML சிறப்பாகச் செயல்படும். ஏதேனும் ஒன்றை மட்டும் தேர்ந்தெடுத்து அதைப் பயன்படுத்தத் தொடங்குங்கள்.

படி 4: ad-hoc கட்டளைகள், அனைத்தும் சரியாக இயங்குவதை உறுதிப்படுத்தும் பச்சை நிறப் பதில்

ansible all -m ping

இது ICMP அல்ல. ping தொகுதி என்பது ஒரு முழுமையான ஒத்திகை ஆகும்: SSH login, தொகுதி நகலெடுத்தல், இலக்கு கணினியில் Python-ஐ இயக்குதல் மற்றும் தற்காலிக கோப்புகளை நீக்குதல் ஆகியவற்றை இது உள்ளடக்கும். சரியான முடிவு பச்சை நிறத்தில், ஒவ்வொரு host-க்கும் ஒரு தொகுதியாகக் காட்டப்படும்:

web1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

பச்சை நிற SUCCESS என்பது authentication, Python interpreter மற்றும் transport ஆகிய அனைத்தும் சரியாக வேலை செய்கின்றன என்பதையும், playbook-ம் சரியாக இயங்கும் என்பதையும் குறிக்கிறது. சிவப்பு நிற UNREACHABLE! என்பது எந்தவொரு தொகுதியும் இயங்குவதற்கு முன்பே transport தோல்வியடைந்துவிட்டது என்பதைக் குறிக்கிறது; இதற்கான துல்லியமான பிழைச் செய்தி மற்றும் தீர்வு கீழே உள்ள தோல்வி முறைகள் (failure modes) பகுதியில் கொடுக்கப்பட்டுள்ளது. தெரிந்துகொள்ள வேண்டிய மேலும் இரண்டு ad-hoc கட்டளைகள்:

ansible all -a "uptime"
ansible all -m apt -a "update_cache=true upgrade=dist" --become

Ad-hoc கட்டளைகள் ஒருமுறை மட்டும் செய்யும் வேலைகளுக்கும், சரிபார்ப்புகளுக்கும் மட்டுமே. நீங்கள் மீண்டும் மீண்டும் செய்ய வேண்டிய எந்தவொரு வேலையையும் playbook-ல் சேர்க்க வேண்டும்.

படி 5: முதல் playbook, புதிய-VPS சரிபார்ப்புப் பட்டியல் (checklist as code)

ஒரு புதிய server-ல் முதல் பத்து நிமிடங்களில் நீங்கள் கைமுறையாகச் செய்யும் அனைத்து வேலைகளும் இதில் உள்ளன. இதை site.yml எனச் சேமிக்கவும்:

---
- name: Baseline a fresh Ubuntu VPS
  hosts: vps
  become: true

  vars:
    deploy_user: deploy
    deploy_pubkey: "{{ lookup('file', '~/.ssh/id_ed25519.pub') }}"
    baseline_packages:
      - fail2ban
      - unattended-upgrades
      - ufw
    baseline_services:
      - fail2ban
      - unattended-upgrades

  tasks:
    - name: Create the deploy user
      ansible.builtin.user:
        name: "{{ deploy_user }}"
        groups: sudo
        append: true
        shell: /bin/bash

    - name: Install the deploy user's SSH key
      ansible.posix.authorized_key:
        user: "{{ deploy_user }}"
        key: "{{ deploy_pubkey }}"

    - name: Passwordless sudo for the deploy user
      ansible.builtin.copy:
        dest: /etc/sudoers.d/deploy
        content: "{{ deploy_user }} ALL=(ALL) NOPASSWD:ALL\n"
        mode: "0440"
        validate: /usr/sbin/visudo -cf %s

    - name: Install baseline packages
      ansible.builtin.apt:
        name: "{{ baseline_packages }}"
        state: present
        update_cache: true

    - name: Enable and start baseline services
      ansible.builtin.service:
        name: "{{ item }}"
        state: started
        enabled: true
      loop: "{{ baseline_services }}"

    - name: Harden sshd with a drop-in
      ansible.builtin.copy:
        dest: /etc/ssh/sshd_config.d/00-hardening.conf
        content: |
          PasswordAuthentication no
          KbdInteractiveAuthentication no
          PermitRootLogin prohibit-password
          X11Forwarding no
        mode: "0644"
        validate: /usr/sbin/sshd -t -f %s
      notify: Restart ssh

    - name: Allow OpenSSH through ufw
      community.general.ufw:
        rule: allow
        name: OpenSSH

    - name: Enable ufw with default deny
      community.general.ufw:
        state: enabled
        policy: deny

  handlers:
    - name: Restart ssh
      ansible.builtin.service:
        name: ssh
        state: restarted

நகலெடுப்பதை விட, புரிந்துகொள்ள வேண்டிய வரிகள்:

Variables என்பவை vars:-ன் கீழ் இருக்கும், அவை "{{ deploy_user }}" மூலம் குறிக்கப்படும். ஒரு மதிப்பு அடைப்புக்குறிக்குள் (brace) தொடங்கினால், முழு expression-ஐயும் மேற்கோள் குறிகளுக்குள் (quote) வைக்கவும், இல்லையெனில் YAML parser அதைத் தவறாகப் புரிந்துகொள்ளும். lookup('file', ...), runtime-ல் உங்கள் control machine-லிருந்து public key-ஐ வாசிக்கும், எனவே playbook-ல் எந்த key தகவலும் இருக்காது.

The loop. loop: "{{ baseline_services }}", service task-ஐ ஒவ்வொரு item-க்கும் ஒருமுறை இயக்கும், output-ல் ஒவ்வொரு item-ம் தனி வரியாகத் தெரியும். apt task, package பட்டியலை மொத்தமாக ஒரே நேரத்தில் கையாளும் என்பதை கவனிக்கவும்; ஒரே apt transaction வேகமாக இருக்கும், இதுவே packages-க்கு பரிந்துரைக்கப்படும் முறை. ஒரு நேரத்தில் ஒரு பொருளை மட்டும் கையாளும் modules-க்கு மட்டுமே loops பயன்படுத்தப்பட வேண்டும்.

The handler என்பது நீங்கள் உள்வாங்க வேண்டிய கருத்து. notify: Restart ssh என்பது "ssh-ஐ இப்போதே restart செய்" என்று அர்த்தமல்ல. இது handler-ஐ வரிசைப்படுத்தும் (queue), இது play-ன் இறுதியில் ஒருமுறை மட்டுமே இயங்கும். அதுவும், notifying task உண்மையில் changed என்று அறிவித்தால் மட்டுமே இயங்கும். நாளை playbook-ஐ மீண்டும் இயக்கினால், drop-in file ஏற்கனவே சரியாக இருக்கும், copy task ok என்று அறிவிக்கும், sshd restart ஆகாது. validate: வரி என்பது trigger-க்கான பாதுகாப்பு; பழைய கோப்பை மாற்றுவதற்கு முன் sshd கோப்பைச் சரிபார்க்கும், எனவே ஏதேனும் பிழை இருந்தால் task தோல்வியடையும், daemon பாதிக்கப்படாது.

no அல்ல, PermitRootLogin prohibit-password-ஐ வேண்டுமென்றே பயன்படுத்துகிறோம். இந்த playbook root பயனர் மூலம் key-ஐப் பயன்படுத்தி login செய்யும். prohibit-password, உங்கள் login-ஐத் தக்கவைத்துக்கொண்டு, root password login-ஐ முடக்கும். deploy user உறுதி செய்யப்பட்டவுடன் (ssh deploy@10.0.0.10 sudo true, இது plain address, ஏனெனில் web1 என்பது Ansible-க்கு மட்டுமே தெரிந்த alias), inventory-ல் ansible_user=deploy-ஐ மாற்றி, அடுத்தடுத்த இயக்கங்களில் அதை no என இறுக்கமாக்கவும். உங்களைச் சிக்கலில் தள்ளாத வகையில், படிப்படியாகப் பாதுகாப்பை அதிகரிக்கவும்.

00- முன்னொட்டு (prefix) முக்கியமானது. பெரும்பாலான keywords-க்கு sshd முதலில் வரும் வரியையே எடுத்துக்கொள்ளும். Ubuntu-வின் sshd_config, அதன் சொந்த body-க்கு முன்னதாகவே sshd_config.d/*.conf-ஐ lexical வரிசையில் உள்ளடக்கியிருக்கும். Ubuntu 24.04 cloud images ஏற்கனவே அந்த directory-ல் 60-cloudimg-settings.conf-ஐக் கொண்டிருக்கும். cloud-init மூலம் password login-ஐ அனுமதிக்கும் providers, PasswordAuthentication yes உடன் 50-cloud-init.conf-ஐச் சேர்க்கும். நம்முடையதை 00-hardening.conf என்று பெயரிடுவதன் மூலம், அது முதலில் வரிசைப்படுத்தப்பட்டு மற்ற இரண்டையும் விட முன்னுரிமை பெறும்.

Task வரிசை firewall பாதுகாப்பிற்கு முக்கியமானது. Allow OpenSSH, deny policy கொண்ட Enable ufw-க்கு முன்பே இயங்க வேண்டும். Ansible பணிகளை வரிசைப்படி மட்டுமே இயக்கும், எனவே firewall சுவர் எழுப்பப்படுவதற்கு முன்பே துளை (hole) இருப்பதை உறுதி செய்ய வேண்டும். இதற்கு fail2ban-க்கு எந்தக் கூடுதல் configuration-ம் தேவையில்லை; அதன் Ubuntu defaults தானாகவே sshd-ஐக் கண்காணிக்கும். jails என்ன செய்யும் மற்றும் எதை மாற்றியமைக்க வேண்டும் என்பது fail2ban on Ubuntu 24.04 guide-ல் விளக்கப்பட்டுள்ளது.

படி 6: --check கொண்டு dry run செய்யவும், பின் உண்மையாக இயக்கவும்

ansible-playbook site.yml --check

Check mode இணைப்பை ஏற்படுத்தி, என்ன செய்யும் என்பதைக் கணக்கிடுமே தவிர, எதையும் மாற்றாது. கீழே உள்ள PLAY RECAP-ல் உள்ள changed= எண்ணிக்கையைப் பார்க்கவும்; இது ஒவ்வொரு host-லும் மாற்றங்களை ஏற்படுத்தும் பணிகளின் எண்ணிக்கையாகும். ஒரு முக்கியமான எச்சரிக்கை: ஒரு பணிக்கு முந்தைய பணியின் மாற்றங்கள் தேவைப்படும் இடங்களில் check mode-க்கு ஒரு கட்டமைப்பு வரம்பு உள்ளது. Ubuntu-வின் standard server image-ல் ufw முன்கூட்டியே இருப்பதால், இந்த playbook dry run-ல் சரியாக இயங்கும். ஆனால், அது இல்லாத minimal image-ல், ufw பணிகள் check mode-ல் fail ஆகும். ஏனெனில், check mode தொகுப்பை (package) நிறுவாது, எனவே module-க்கு அழைப்பு விடுக்க ஏதுமிருக்காது. இது dry run-ன் வரம்பு, உங்கள் playbook-ல் உள்ள பிழை அல்ல. திட்டம் சரியாகத் தெரிந்தால்:

ansible-playbook site.yml

ஒவ்வொரு பணியும் ஒவ்வொரு host-க்கும் ஒரு வரியை அச்சிடும்; மஞ்சள் நிற changed, பச்சை நிற ok, மற்றும் recap பின்வருமாறு இருக்க வேண்டும்:

PLAY RECAP *********************************************************************
web1 : ok=10  changed=9  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
web2 : ok=10  changed=9  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

பத்து ok என்பது fact-gathering மற்றும் எட்டு பணிகள் மற்றும் handler ஆகும். உங்கள் changed என்னிடமிருந்து ஒன்று அல்லது இரண்டு எண்ணிக்கையில் மாறுபடலாம்: Ubuntu-வின் standard image-ல் ufw மற்றும் unattended-upgrades முன்கூட்டியே இருக்கும். மேலும், apt மூலம் நிறுவியவுடன் fail2ban தானாகவே தொடங்கிவிடும், எனவே ஒரு பணி முதல் முறையே ok என்று காட்டலாம், ஏனெனில் அது கோரிய நிலை ஏற்கனவே அங்கு உள்ளது. unreachable மற்றும் failed ஆகியவை கண்டிப்பாக பூஜ்ஜியமாக இருக்க வேண்டும். become: true குறித்த ஒரு குறிப்பு: நீங்கள் root-ஆக இணையும் வரை இது ஒரு சம்பிரதாயம் மட்டுமே. ஆனால், நீங்கள் ansible_user-ஐ deploy-க்கு மாற்றியவுடன், sudo உண்மையாகிவிடும். இந்த playbook நிறுவும் NOPASSWD sudoers கோப்புதான் உங்கள் command line-ல் -K வராமல் தடுக்கிறது. அது இல்லையென்றால், கீழே விவரிக்கப்பட்டுள்ள Missing sudo password பிழையைப் பெறுவீர்கள்.

படி 7: இரண்டு முறை இயக்குதல், idempotence என்றால் என்ன

அதே கட்டளையை உடனடியாக மீண்டும் இயக்கவும்:

web1 : ok=9  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

changed=0, மற்றும் ok ஆகியவை ஒன்று குறைந்திருக்கும், ஏனெனில் அறிவிக்கப்படாத handler இயங்கவில்லை. எதுவும் மீண்டும் நிறுவப்படவில்லை, sshd மறுதொடக்கம் செய்யப்படவில்லை, ufw மாற்றப்படவில்லை. இதுவே ஒரு playbook-ஐ ஒரு provisioner-ஆக மட்டுமல்லாமல், ஒரு audit கருவியாகவும் மாற்றுகிறது: அடுத்த மாதம் inventory-ல் web3-ஐச் சேர்த்து மீண்டும் இயக்கினால், புதிய box உருவாக்கப்படும், பழைய box-கள் சரிபார்க்கப்படும். நீங்கள் மாற்றாத ஒரு box-ல் பூஜ்ஜியமற்ற changed இருந்தால், அது drift ஆகும்; playbook மூலம் மாற்றப்பட வேண்டியதை யாரோ கைமுறையாக மாற்றியுள்ளனர் என்பதை இது உணர்த்துகிறது.

இங்கிருந்து இந்த முறை மேலும் விரிவடைகிறது. அடுத்து எழுத வேண்டிய playbook, அதே VPS-ல் WireGuard VPN-ஐ அமைத்து, SSH tunnel வழியாக மட்டுமே பதிலளிக்கும்படி ufw விதியை இறுக்க வேண்டும்; அதன் பிறகு, ஒவ்வொரு app server-லும் Docker மற்றும் Compose-ஐ நிறுவும் playbook-ஐ உருவாக்கலாம். site.yml மூன்று திரைகளைத் தாண்டினால், அதை roles-ஆகப் பிரிக்கவும், அதற்கு முன் வேண்டாம்.

தோல்விக்கான காரணங்கள் மற்றும் நீங்கள் காணக்கூடிய செய்திகள்

Permission denied பிழையுடன் UNREACHABLE.

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: root@10.0.0.10: Permission denied (publickey).",
    "unreachable": true
}

எந்தவொரு module-ம் இயங்குவதற்கு முன்பே SSH transport தோல்வியடைந்தது: ansible_user தவறாக உள்ளது, அந்த host-க்கு key நகலெடுக்கப்படவில்லை, அல்லது தவறான key வழங்கப்படுகிறது. சாதாரண ssh root@10.0.0.10 கட்டளையைப் பயன்படுத்தி இதை மீண்டும் சோதிக்கவும், பின்னர் எந்தெந்த keys வழங்கப்படுகின்றன என்பதைப் பார்க்க ssh -v கட்டளையைப் பயன்படுத்தவும். password-ஐப் பயன்படுத்தும் SSH வேலை செய்கிறது, ஆனால் Ansible வேலை செய்யவில்லை என்றால், நீங்கள் ssh-copy-id-ஐத் தவிர்த்துவிட்டீர்கள் என்று அர்த்தம்.

sudo password விடுபட்டுள்ளது.

web1 | FAILED! => {
    "msg": "Missing sudo password"
}

நீங்கள் become: true-ஐ அமைத்து, root அல்லாத பயனராக இணைந்திருக்கிறீர்கள், அந்தப் பயனருக்கு sudo-விற்கு password தேவைப்படுகிறது. கட்டளை வரியில் -K (--ask-become-pass)-ஐச் சேர்க்கவும், அல்லது அந்தப் பயனருக்கு NOPASSWD sudoers பதிவை வழங்கவும். இதனால்தான் நீங்கள் அந்தப் பயனருக்கு மாறுவதற்கு முன்பே playbook deploy-க்காக ஒன்றை நிறுவுகிறது.

error: externally-managed-environment. நீங்கள் Ubuntu 24.04-ல் உள்ள system Python-க்கு எதிராக pip-ஐ இயக்கியுள்ளீர்கள். இது முதல் படியிலேயே விளக்கப்பட்டுள்ளது: pip-ஐப் பயன்படுத்த வேண்டாம், pipx-ஐப் பயன்படுத்தவும், மேலும் --break-system-packages-ஐயும் பயன்படுத்த வேண்டாம்.

mapping values are not allowed in this context.

ERROR! Syntax Error while loading YAML.
  mapping values are not allowed in this context

இது பெரும்பாலும் indentation பிழையாகவே இருக்கும்: ஒரு key தவறான ஆழத்தில் இருப்பது அல்லது colon-க்கு பிறகு இடைவெளி (space) விடுபட்டிருப்பது. காட்டப்படும் வரி எண் பிழைக்கு அருகில் உள்ளதைக் குறிக்கும், சரியாக அந்த வரியைக் குறிக்காது, அதற்கு முந்தைய வரியையும் சரிபார்க்கவும். இதன் தொடர்புடைய பிழையான found character '\t' that cannot start any token என்பது tab பயன்படுத்தப்பட்டதைக் குறிக்கிறது; YAML-ல் tab பயன்படுத்த அனுமதி இல்லை. ஒவ்வொரு முறை இயக்கும் முன்பும் ansible-playbook site.yml --syntax-check-ஐ ஒரு பழக்கமாக மாற்றிக்கொள்ளுங்கள், மேலும் உங்கள் editor-ஐ YAML-க்காக இரண்டு-இடைவெளி (two-space) indentation-க்கு அமைக்கவும்.

/usr/bin/python3: not found. தரமான Ubuntu 24.04 images-ல் இது அரிது, ஆனால் minimal அல்லது netboot images-ல் இது பொதுவானது: target-ல் Python இல்லாததால் module execution தோல்வியடைகிறது. இதைச் சரிசெய்ய raw module-ஐப் பயன்படுத்தி bootstrap செய்யவும், இது மட்டுமே target-ல் எதையும் எதிர்பார்க்காத module ஆகும்: ansible all -m raw -a "apt-get update && apt-get install -y python3" --become, அதன் பிறகு playbook-ஐ மீண்டும் இயக்கவும்.

FAQ

நான் நிர்வகிக்கும் server-களில் Ansible-ஐ நிறுவ வேண்டுமா?

இல்லை. Ansible-க்கு agent தேவையில்லை: control machine சிறிய Python modules-ஐ SSH வழியாக அனுப்பி, இயக்கி, பின் அவற்றை நீக்கிவிடும். இலக்கு server-ல் python3 மற்றும் SSH access மட்டுமே இருக்க வேண்டும்; இவை இரண்டும் பொதுவான Ubuntu images-ல் ஏற்கனவே இருக்கும். இந்த வழிகாட்டி முழுவதிலும், உங்கள் control machine-ல் மட்டுமே நிறுவல் செய்யப்படுகிறது.

Ansible ஏன் "Permission denied (publickey)" என்று காட்டுகிறது?

UNREACHABLE! மற்றும் Permission denied (publickey) கொண்ட block, Ansible எதையும் இயக்கும் முன்பே SSH authentication தோல்வியடைந்ததைக் குறிக்கிறது. inventory-ல் உள்ள ansible_user, நீங்கள் உருவாக்கிய account-உடன் ஒத்துப்போகிறதா என்பதையும், அந்த host-க்கு ssh-copy-id செய்துள்ளீர்களா என்பதையும், கடவுச்சொல் இன்றி ssh user@host மூலம் login செய்ய முடிகிறதா என்பதையும் சரிபார்க்கவும். plain ssh command-ஐச் சரிசெய்யும் எந்தவொரு நடவடிக்கையும் Ansible-ஐயும் சரிசெய்யும், ஏனெனில் இவை இரண்டும் ஒரே transport-ஐப் பயன்படுத்துகின்றன.

Ansible-ல் idempotent என்பதன் பொருள் என்ன?

ஒரு task, "இந்த package இருக்க வேண்டும்" அல்லது "இந்த வரியில் இந்த வாசகம் இருக்க வேண்டும்" என்ற இலக்கு நிலையை மட்டுமே குறிப்பிடுகிறது, ஒரு செயலைச் செய்வதை அல்ல. அந்த நிலை ஏற்கனவே இருந்தால், Ansible எதையும் செய்யாது மற்றும் changed-க்கு பதிலாக ok என்று காட்டும். இதனால்தான் ஒரு playbook-ஐ இரண்டு முறை இயக்கும்போது இரண்டாவது முறை changed=0 என்று காட்டுகிறது, மேலும் மீண்டும் இயக்குவது என்பது ஆபத்தான மறுநிறுவல் அல்ல, மாறாக பாதுகாப்பான தணிக்கையாகும்.

Ubuntu 24.04-ல் Ansible-ஐ நிறுவ pip அல்லது pipx எதைப் பயன்படுத்த வேண்டும்?

pipx-ஐப் பயன்படுத்தவும். Ubuntu 24.04-ல் system Python வெளிப்புறமாக நிர்வகிக்கப்படுவதால், pip install ansible கட்டளை error: externally-managed-environment பிழையுடன் தோல்வியடையும். pipx install --include-deps ansible, Ansible-ஐ ஒரு தனிமைப்படுத்தப்பட்ட virtualenv-ல் வைத்து, ansible, ansible-playbook மற்றும் பிறவற்றை உங்கள் PATH-ல் தெளிவாக இணைக்கிறது.

ansible மற்றும் ansible-core packages-க்கு என்ன வித்தியாசம்?

ansible-core என்பது engine மற்றும் அதனுடன் சில ansible.builtin modules-ஐ மட்டுமே கொண்டது. ansible package, core-உடன் சேர்த்து சமூகத்தால் தேர்ந்தெடுக்கப்பட்ட collections-ஐயும் கொண்டுள்ளது. இதில் இந்த வழிகாட்டியில் பயன்படுத்தப்படும் ansible.posix (authorized_key module) மற்றும் community.general (ufw module) ஆகியவையும் அடங்கும். முழுமையான package-உடன் தொடங்கவும்; தேவைப்படும்போது மட்டும் core மற்றும் குறிப்பிட்ட collections-க்கு மாறவும்.

#ansible #automation #ubuntu #devops