Ansible tutorial: VPS-ல் முதல் playbook

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

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

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

Ansible என்பது உண்மையில் என்ன, ஒரு பத்தியில்

Ansible என்பது agentless ஆகும். இது நிர்வகிக்கும் servers-களில் எந்த daemon-ஐயும் install செய்யத் தேவையில்லை: control machine சாதாரண SSH வழியாகத் தொடர்பு கொள்கிறது, target-க்கு ஒரு சிறிய Python module-ஐ நகலெடுக்கிறது, அதை execute செய்கிறது, அது print செய்யும் JSON-ஐ வாசிக்கிறது, பிறகு அதை நீக்கிவிடுகிறது. target-க்குத் தேவையான ஒரே விஷயம் python3 மட்டுமே, இது அனைத்து stock Ubuntu image-களிலும் ஏற்கனவே உள்ளது. இதில் முக்கியமான சொல் idempotent என்பதாகும், இதன் பொருள் மிக எளிமையானது: ஒரு task என்பது ஒரு state-ஐ விவரிக்கிறது, ஒரு action-ஐ அல்ல. ஒரு package-க்கான state: present என்பது "இதை install செய்திருப்பதை உறுதி செய்" என்று பொருள்படுகிறதே தவிர, "installer-ஐ run செய்" என்று பொருள்படாது. அந்த state ஏற்கனவே இருந்தால், Ansible எதையும் மாற்றாமல், அதை changed என்பதற்குப் பதிலாக ok என்று report செய்யும். இந்தத் தன்மையே இந்தத் தயாரிப்பின் அடிப்படை — இதுவே ஒரு playbook-ஐ மீண்டும் மீண்டும் பாதுகாப்பாக run செய்ய உதவுகிறது, மேலும் பாதுகாப்பான reruns தான் ஒரு shell script-ஐ infrastructure ஆக மாற்றுகிறது.

Prerequisites, and the gotchas up front

• ஒரு control machine: உங்கள் laptop அல்லது ஒரு சிறிய VPS. நான் Ubuntu 24.04 பயன்படுத்துவதாகக் கருதுகிறேன்; Homebrew மூலம் pipx நிறுவியிருந்தால் macOS-லும் இது একইভাবে செயல்படும்.
• KVM-இல் Ubuntu 24.04 இயங்கும் ஒன்று அல்லது அதற்கு மேற்பட்ட target VPSes; இவற்றை root பயனராக அணுக முடிய வேண்டும். இவற்றில் எந்த மென்பொருளும் install செய்யப்படாது.
• ஒவ்வொரு target-க்கும் SSH key authentication அவசியம். உங்கள் ssh command எவ்வாறு authenticate செய்யப்படுகிறதோ, அதேபோலவே Ansible-உம் செயல்படும் — ஒருவேளை ssh root@host password கேட்கத் தொடங்கினால், Ansible fail ஆகும்.
• Ubuntu 24.04-இல், pip install ansible ஆனது error: externally-managed-environment காரணமாக செயலிழக்கும். இது ஒரு வேண்டுமென்றே எடுக்கப்பட்ட distro policy, பிழை அல்ல. pipx பயன்படுத்தவும்.
• YAML whitespace என்பது syntax ஆகும். தவறான indent mapping values are not allowed in this context பிழையை ஏற்படுத்தும், மேலும் எங்கு வேண்டுமானாலும் ஒரு tab character இருந்தால் அது fatal error ஆகும்.
• Playbook மூலம் sshd-ஐ harden செய்யும் போது, ஒவ்வொரு target-இலும் ஒரு working SSH session-ஐ திறந்து வைத்திருக்கவும். "சுத்தமான முறையில் test செய்ய வேண்டும்" என்பதற்காக கடைசி session-ஐ மூடியதால்தான், நான் வாடிக்கையாளர்களுக்குச் செய்த recovery பணிகளில் lockout பிரச்சனைகள் ஏற்பட்டன.

Step 1: pip-ஐப் பயன்படுத்தாமல், pipx மூலம் control machine-இல் Ansible-ஐ install செய்யவும்

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

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-க்குத் தனியான isolated virtualenv-ஐ உருவாக்கி, அதன் binaries-களை உங்கள் PATH-இல் சேர்க்கிறது:

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

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

ansible --version

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

இதுவே முழுமையான installation ஆகும். target machines-இல் எந்த மாற்றமும் செய்யப்படாது.

Step 2: SSH key access to every target

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 auth வேலை செய்கிறது என்பதை இது உறுதிப்படுத்துகிறது, மேலும் host key-ஐ known_hosts கோப்பில் பதிவு செய்கிறது. இதை இப்போதே செய்துவிடவும், ஏனெனில் Ansible ஒரு unrecorded host key-ஐக் கண்டறிந்தால், அது ஒரு interactive prompt ஆகத் தோன்றும். இது ஒரு run-இன் நடுவில் மறைந்திருக்கும், இதனால் system hang ஆனது போன்றே தோற்றமளிக்கும்.

Step 3: the inventory — INI first, YAML when it grows

Inventory என்பது Ansible அணுகக்கூடிய machines பட்டியலிடப்பட்ட ஒரு 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 மூலம் நீங்கள் target செய்யும் பெயராக இருக்கும். ansible_host என்பது உண்மையான address ஆகும். [vps] என்பது ஒரு group, மற்றும் [vps:vars] அந்த group-இல் உள்ள ஒவ்வொரு host-க்கும் variables-ஐ அமைக்கும்; ansible_user என்பது Ansible எந்த user மூலம் log in செய்ய வேண்டும் என்பதைக் குறிக்கும். அதன் அருகில், -i-ஐ மீண்டும் மீண்டும் தட்டச்சு செய்யத் தேவையில்லை என்பதற்காக ஒரு ansible.cfg உள்ளது:

[defaults]
inventory = inventory.ini

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

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

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

Step 4: ad-hoc commands — the green pong that proves everything

ansible all -m ping

இது ICMP அல்ல. ping module ஒரு முழுமையான rehearsal ஆகும்: SSH login, module copy, target-இல் Python execution மற்றும் cleanup ஆகியவற்றை இது உள்ளடக்கியது. சரியான முடிவு பச்சை நிறத்தில் (green) இருக்க வேண்டும், ஒவ்வொரு host-க்கும் ஒரு block வர வேண்டும்:

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

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

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

Ad-hoc என்பது ஒருமுறை மட்டும் தேவைப்படும் పనులు மற்றும் checks-களுக்கு மட்டுமே. நீங்கள் இரண்டு முறை இயக்க வேண்டிய எந்தவொரு கட்டளையும் playbook-இல் இருக்க வேண்டும்.

Step 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 }}" மூலம் குறிப்பிடலாம் — ஒரு value brace-இல் தொடங்கினால், முழு expression-ஐயும் quote செய்யவும், இல்லையெனில் YAML parser தவறாகப் புரிந்துகொள்ளும். lookup('file', ...) என்பது runtime-இல் control machine-இல் இருந்து உங்கள் public key-ஐப் படிக்கிறது, எனவே playbook-இல் எந்த key material-உம் இருக்காது.

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

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

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

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

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

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

ansible-playbook site.yml --check

Check mode என்பது இணைப்பை ஏற்படுத்தி, என்ன செய்யப் போகிறது என்பதைக் கணக்கிடும், ஆனால் எந்த மாற்றத்தையும் செய்யாது. இறுதியில் உள்ள PLAY RECAP பகுதியில் உள்ள changed= எண்ணிக்கையைச் சரிபார்க்கவும் — இது ஒவ்வொரு host-ஐயும் மாற்றியமைக்கப் போகும் tasks-களின் எண்ணிக்கையாகும். ஒரு முக்கியக் குறிப்பு: ஒரு task-ன் மாற்றங்களை அடுத்தடுத்த task சார்ந்து இருக்கும்போது, check mode-ல் ஒரு structural limit இருக்கும். Ubuntu-ன் standard server image-ல் ufw ஏற்கனவே இருக்கும், எனவே இந்த playbook எந்தப் பிரச்சனையும் இன்றி dry-run ஆகும் — ஆனால் ufw இல்லாத minimal image-ல், check mode-ல் uufw tasks fail ஆகும். ஏனெனில் check mode package-ஐ உண்மையில் install செய்யாது, அதனால் module-ஆல் எதையும் அழைக்க முடியாது. இது dry run-ன் ஒரு வரம்பு மட்டுமே, உங்கள் playbook-ல் உள்ள bug அல்ல. திட்டம் சரியாகத் தெரிந்தால்:

ansible-playbook site.yml

ஒவ்வொரு task-ம் ஒவ்வொரு host-க்கும் ஒரு வரியைப் printed செய்யும் — மஞ்சள் 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 மற்றும் எட்டு tasks மற்றும் handler ஆகியவற்றைச் சேர்த்து வரும். உங்கள் changed எண்ணிக்கையானது என்னுடையதை விட ஒன்று அல்லது இரண்டு வித்தியாசப்படலாம்: Ubuntu-ன் standard image-ல் ufw மற்றும் unattended-upgrades ஏற்கனவே இருக்கும், மேலும் apt install செய்தவுடன் fail2ban தானாகவே தொடங்கும், எனவே ஒரு task அதன் முதல் run-லேயே ok என்று தகுதியுடன் report செய்யலாம் — அதாவது அந்தத் தற்போதைய நிலை ஏற்கனவே உள்ளது என்று அர்த்தம். unreachable மற்றும் failed ஆகிய எண்கள் கண்டிப்பாக பூஜ்ஜியமாக (zero) இருக்க வேண்டும். become: true பற்றிய ஒரு குறிப்பு: நீங்கள் root-ஆக இணைக்கும்போது இது ஒரு formality மட்டுமே, ஆனால் நீங்கள் ansible_user ஐ deploy ஆக மாற்றியவுடன், sudo உண்மையானதாக மாறும் — இந்த playbook install செய்யும் NOPASSWD sudoers file தான் -K ஐ உங்கள் command line-ல் வராமல் தடுக்கிறது. அது இல்லையென்றால் உங்களுக்கு Missing sudo password வரும், இது கீழே விளக்கப்பட்டுள்ளது.

Step 7: இரண்டு முறை இயக்கவும் — idempotence என்பது எப்படி இருக்கும்

அதே command-ஐ உடனடியாக மீண்டும் இயக்கவும்:

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

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

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

Failure modes, with the strings you will see

UNREACHABLE with Permission denied.

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 தவறானது, key அந்த host-க்கு நகலெடுக்கப்படவில்லை, அல்லது தவறான key பயன்படுத்தப்படுகிறது. இதைச் சரிபார்க்க முதலில் plain ssh root@10.0.0.10 பயன்படுத்தவும், பின்னர் எந்த keys வழங்கப்பட்டன என்பதை அறிய ssh -v பயன்படுத்தவும். Password SSH வேலை செய்கிறது ஆனால் Ansible வேலை செய்யவில்லை என்றால், நீங்கள் ssh-copy-id செய்திருக்கவில்லை என்று அர்த்தம்.

Missing sudo password.

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

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

error: externally-managed-environment. நீங்கள் Ubuntu 24.04-இல் உள்ள system Python-இல் pip-ஐ இயக்க முயன்றீர்கள். இது step 1-இல் விளக்கப்பட்டுள்ளது: pipx பயன்படுத்த வேண்டும், pip அல்ல, மேலும் --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 தவறான depth-இல் உள்ளது, அல்லது colon-க்கு பின் space விடுபட்டுள்ளது. காட்டப்படும் line number பிழைக்கு அருகில் இருக்கும், பிழையைத் துல்லியமாகக் காட்டாது — அதற்கு முந்தைய line-ஐயும் சரிபார்க்கவும். இதன் தொடர்புடைய 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 system-இல் Python இல்லாததால் module execution தோல்வியடைகிறது. இதைத் தவிர்க்க raw module மூலம் bootstrap செய்யவும்; இதுவே target side-இல் எதையும் எதிர்பார்க்காத ஒரே module: ansible all -m raw -a "apt-get update && apt-get install -y python3" --become, அதன் பிறகு playbook-ஐ மீண்டும் இயக்கவும்.

FAQ

Ansible-ஐ அது நிர்வகிக்கும் servers-களில் install செய்ய வேண்டுமா?

தேவையில்லை. Ansible என்பது agentless தொழில்நுட்பமாகும்: control machine ஆனது SSH வழியாக சிறிய Python modules-களை அனுப்பி, அவற்றை இயக்கிவிட்டு, பிறகு நீக்கிவிடும். target machine-க்கு python3 மற்றும் SSH access மட்டுமே போதுமானது; இவை அனைத்தும் stock Ubuntu images-களில் ஏற்கனவே இருக்கும். இந்த guide-இல் உள்ள அனைத்து கட்டளைகளும் உங்கள் control machine-இல் மட்டுமே இயங்கும்.

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

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

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

ஒரு task என்பது செய்ய வேண்டிய செயலைச் சொல்வதற்குப் பதிலாக, இருக்க வேண்டிய நிலையை (desired state) அறிவிக்கிறது — உதாரணமாக, "இந்த package இருக்க வேண்டும்" அல்லது "இந்த line இந்த file-இல் இருக்க வேண்டும்". அந்த நிலை ஏற்கனவே இருந்தால், Ansible எதையும் செய்யாது, changed என்பதற்குப் பதிலாக ok என்று report செய்யும். இதனால்தான் ஒரு playbook-ஐ இருமுறை இயக்கும்போது, இரண்டாவது முறை changed=0 என்று காட்டுகிறது; எனவே மறுமுறை இயக்குவது ஒரு பாதுகாப்பான audit முறையே தவிர, ஆபத்தான re-install முறை அல்ல.

Ubuntu 24.04-இல் Ansible install செய்ய pip அல்லது pipx பயன்படுத்த வேண்டுமா?

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

ansible மற்றும் ansible-core packages-களுக்கு இடையிலான வேறுபாடு என்ன?

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