Ansible

01Գաղափարը՝ ցանկալի վիճակ SSH-ով

Պատկերացրու, որ ստուգաթերթ ես գրում սերվերի կարգավորման համար․ տեղադրել nginx, պատճենել կոնֆիգը, բացել 443 պորտը, գործարկել ծառայությունը։ Ansible-ը այդ ստուգաթերթը վերածում է կոդի։ Control node-ը՝ քո laptop-ը կամ CI runner-ը, որի վրա Ansible տեղադրված է, SSH-ով միանում է managed node-երին, պատճենում է փոքր Python մոդուլներ, աշխատեցնում դրանք և հեռացնում։ Յուրաքանչյուր task կանչում է մոդուլ, օրինակ՝ apt, copy, template, user կամ service, և նկարագրում է վերջնական վիճակը (state: present, state: started), ոչ թե այնտեղ հասնելու հրամանները։ Մոդուլը նախ ստուգում է ընթացիկ վիճակը և փոխում միայն այն, ինչը տարբերվում է՝ հաղորդելով ok կամ changed։ Այդ հատկությունը՝ idempotency-ն, նշանակում է, որ կարող ես նույն playbook-ը աշխատեցնել ամեն օր որպես drift-ի ստուգում։ Ansible-ը տարածվում է որպես ansible-core (շարժիչը և ներկառուցված մոդուլները) գումարած collection-ներ՝ ամպերի, տվյալների բազաների և ցանցային սարքերի մոդուլների փաթեթներ, որոնք միասին հավաքված են ansible community փաթեթում։

• Control node՝ որտեղ աշխատում է Ansible-ը։ Managed node-եր՝ սերվերները։
• Մոդուլ՝ աշխատանքի միավոր (apt, template, service)։
• Idempotent՝ երկրորդ run-ը հաղորդում է ok, ոչ թե changed։

02Տեղադրում, inventory և ad-hoc հրամաններ

Ansible-ը control node-ի վրա տեղադրիր pipx-ով կամ pip-ով առանձին միջավայրում, ինչը խուսափում է համակարգային Python-ի հետ կոնֆլիկտներից։ Inventory-ն թվարկում է managed host-երը և խմբավորում դրանք՝ INI կամ YAML ձևաչափով։ Խմբերը թույլ են տալիս առանձին թիրախավորել վեբ սերվերները կամ տվյալների բազաները, իսկ group_vars/ և host_vars/ թղթապանակները պահում են փոփոխականներ ըստ խմբի կամ host-ի։ Playbook-ներ գրելուց առաջ ստուգիր կապը ad-hoc հրամաններով՝ մեկանգամյա մոդուլի կանչեր հրամանի տողից։ ansible all -m ping-ը ICMP չի օգտագործում․ այն մուտք է գործում SSH-ով և ստուգում Python-ը։ Օգտագործիր SSH բանալիներ և ոչ root օգտատեր sudo-ով․ Ansible-ի become: true-ն բարձրացնում է իրավունքները այն task-երի համար, որոնց դա պետք է։ ansible.cfg-ն պահիր նախագծում՝ inventory-ի ուղին և խելամիտ լռելյայն արժեքները սահմանելու համար։

1# install on the control node
2pipx install --include-deps ansible
3 
4# inventory.yml
5all:
6  children:
7    web:
8      hosts:
9        web1: { ansible_host: 203.0.113.10 }
10        web2: { ansible_host: 203.0.113.11 }
11  vars:
12    ansible_user: your_user
13 
14# test connectivity and gather facts
15ansible -i inventory.yml all -m ping
16ansible -i inventory.yml web -m ansible.builtin.setup -a "filter=ansible_distribution*"

03Քո առաջին playbook-ը

Playbook-ը play-երի ցուցակ է․ յուրաքանչյուր play թիրախավորում է host-եր և հերթով աշխատեցնում task-եր։ Օրինակը web խմբի վրա տեղադրում է nginx, Jinja2 template-ից deploy անում կայքի կոնֆիգուրացիան և համոզվում, որ ծառայությունը աշխատում է։ notify տողը handler է գործարկում միայն այն դեպքում, երբ template-ն իսկապես փոխվել է, ուստի nginx-ը reload է լինում մեկ անգամ՝ play-ի վերջում, ոչ թե ամեն run-ի ժամանակ։ Միշտ օգտագործիր մոդուլների լիարժեք անուններ, օրինակ՝ ansible.builtin.apt, որոնք պարզ են դարձնում, թե որ collection-ից է մոդուլը։ Նախ աշխատեցրու --check --diff-ով՝ տեսնելու, թե ինչ կփոխվի առանց որևէ բան փոխելու, հետո՝ իրականում։ Երկրորդ իրական run-ը պետք է ցույց տա changed=0․ եթե ոչ, ինչ-որ task idempotent չէ և պետք է ուղղվի։

1- name: Configure web servers
2  hosts: web
3  become: true
4  tasks:
5    - name: Install nginx
6      ansible.builtin.apt:
7        name: nginx
8        state: present
9        update_cache: true
10    - name: Deploy site config
11      ansible.builtin.template:
12        src: templates/site.conf.j2
13        dest: /etc/nginx/sites-available/default
14        mode: "0644"
15      notify: Reload nginx
16    - name: Ensure nginx is running
17      ansible.builtin.service: { name: nginx, state: started, enabled: true }
18  handlers:
19    - name: Reload nginx
20      ansible.builtin.service: { name: nginx, state: reloaded }

04Փոփոխականներ, template-ներ և secret-ներ

Փոփոխականները թույլ են տալիս մեկ playbook-ին աշխատել բազմաթիվ միջավայրերի համար․ նույն role-ը կարգավորում է staging-ը և production-ը տարբեր արժեքներով՝ group_vars/staging.yml-ից և group_vars/production.yml-ից։ Template-ները օգտագործում են Jinja2 syntax՝ {{ variable }} և պարզ ցիկլեր կամ պայմաններ, այդ փոփոխականներից կոնֆիգուրացիոն ֆայլեր render անելու համար։ Facts-ը փոփոխականներ են, որոնք Ansible-ը ավտոմատ հավաքում է յուրաքանչյուր host-ից, օրինակ՝ OS-ի տարբերակը, հիշողությունը և IP հասցեները, օգտակար when: ansible_distribution == 'Ubuntu'-ի նման պայմանների համար։ Փոփոխականների precedence-ը շատ մակարդակներ ունի․ պահիր այն պարզ՝ օգտագործելով role default-ներ խելամիտ արժեքների համար և group_vars՝ միջավայրի override-ների համար։ Secret-ների համար Ansible Vault-ը գաղտնաբառով գաղտնագրում է ֆայլեր կամ առանձին արժեքներ, ուստի դրանք կարող են ապահով ապրել Git-ում։ CI-ում vault գաղտնաբառը տուր CI-ի secret store-ից կամ secret-ները վերցրու աշխատանքի պահին manager-ից, օրինակ՝ HashiCorp Vault-ից, lookup plugin-ով։

1# group_vars/production/vars.yml
2app_domain: example.com
3app_workers: 4
4db_password: "{{ vault_db_password }}"
5 
6# group_vars/production/vault.yml (encrypted)
7# ansible-vault create group_vars/production/vault.yml
8# vault_db_password: change-me
9 
10# run with the vault password
11ansible-playbook -i inventory.yml site.yml --ask-vault-pass

05Role-եր և collection-ներ․ կառուցվածք, որը scale է լինում

Երբ playbook-ները մեծանում են, բաժանիր դրանք role-երի՝ ստանդարտ թղթապանակային կառուցվածք tasks-ով, handlers-ով, templates-ով, files-ով, defaults-ով և meta-ով։ Role-ը լավ է անում մեկ բան, օրինակ՝ nginx, postgres կամ base hardening baseline, իսկ site playbook-ը role-երը համադրում է ըստ host խմբերի։ ansible-galaxy role init-ը ստեղծում է կմախքը։ Collection-ները role-երը, մոդուլները և plugin-ները փաթեթավորում են միասին namespace-ի տակ, և դու դրանք տեղադրում ես Ansible Galaxy-ից կամ private hub-ից requirements.yml-ով՝ ամրացված տարբերակներով, ինչպես կամրացնեիր npm փաթեթները։ Role-երը թեստավորիր Molecule-ով, որը գործարկում է container կամ VM, կիրառում role-ը, նորից աշխատեցնում այն idempotency-ն ստուգելու համար և ստուգում արդյունքը։ CI-ում lint արա ansible-lint-ով՝ հնացած syntax-ը, բացակայող անունները և ռիսկային pattern-ները բռնելու համար։

1# requirements.yml
2collections:
3  - name: community.general
4    version: ">=10.0.0,<11.0.0"
5  - name: ansible.posix
6    version: ">=2.0.0"
7 
8# site.yml
9- hosts: web
10  become: true
11  roles:
12    - base_hardening
13    - nginx
14 
15# ansible-galaxy collection install -r requirements.yml

06Ինչպես է task-ը իրականում կատարվում

Յուրաքանչյուր task-ի համար Ansible-ը control node-ի վրա Jinja2-ով render է անում մոդուլի արգումենտները, փաթեթավորում մոդուլի կոդը (AnsiballZ) և ուղարկում SSH-ով, հետո աշխատեցնում այն հեռավոր Python-ով և հետ կարդում JSON։ Լռելյայն այն դա անում է միաժամանակ forks host-ի համար (լռելյայն 5) linear strategy-ով, որտեղ ամեն host ավարտում է task-ը, մինչև որևէ host սկսի հաջորդը։ Մեծ մասշտաբում կատարողականի կարգավորումը կարևոր է․ մեծացրու forks-ը, ansible.cfg-ում միացրու pipelining (այն հեռացնում է SSH-ի լրացուցիչ round-trip-ները, բայց պահանջում է, որ sudo-ն TTY չպահանջի), պահիր SSH ControlPersist multiplexing-ը միացված և անջատիր կամ cache արա fact-երի հավաքումը, երբ fact-եր պետք չեն։ Free strategy-ն թույլ է տալիս արագ host-երին առաջ անցնել։ Երկար task-երը կարող են աշխատել ասինխրոն async-ով և poll-ով, որպեսզի կապերը բաց չպահվեն։

1# ansible.cfg
2[defaults]
3inventory = inventory.yml
4forks = 25
5gathering = smart
6fact_caching = jsonfile
7fact_caching_connection = .ansible_facts
8fact_caching_timeout = 3600
9 
10[ssh_connection]
11pipelining = True
12ssh_args = -o ControlMaster=auto -o ControlPersist=60s

07Rolling update-ներ serial-ով և health check-երով

Production-ի փոփոխությունները երբեք չպետք է միանգամից հասնեն բոլոր host-երին։ serial-ը ընդունում է թիվ, տոկոս կամ ցուցակ, օրինակ՝ [1, 5, "25%"], ինչը տալիս է canary host, հետո փոքր խմբաքանակ, հետո ավելի մեծերը։ delegate_to-ն task-ը աշխատեցնում է այլ մեքենայի վրա, սովորաբար ընթացիկ host-ը load balancer-ից հանելու համար։ until-ի և retries-ի հետ համատեղ health check-ը սպասում է, մինչև ծառայությունը առողջ դառնա, նախքան առաջ շարժվելը։ max_fail_percentage-ը դադարեցնում է play-ը, երբ խմբաքանակում չափազանց շատ host-եր են ձախողվում, ինչը կանգնեցնում է վատ release-ի տարածումը։ any_errors_fatal-ը կանգնեցնում է ամեն ինչ առաջին ձախողման ժամանակ, ինչը օգտակար է տվյալների բազաների կլաստերների համար, որտեղ մասնակի փոփոխությունները վտանգավոր են։

1- hosts: web
2  become: true
3  serial: [1, 5, "25%"]
4  max_fail_percentage: 0
5  tasks:
6    - name: Deploy new release
7      ansible.builtin.include_role: { name: app_release }
8    - name: Wait until healthy
9      ansible.builtin.uri:
10        url: "http://{{ ansible_host }}:8080/healthz"
11        status_code: 200
12      register: health
13      until: health.status == 200
14      retries: 20
15      delay: 3
16      delegate_to: localhost

08Dynamic inventory, AWX և Execution Environment-ներ

Ստատիկ inventory ֆայլերը ամպում արագ հնանում են։ Inventory plugin-ները, օրինակ՝ amazon.aws.aws_ec2, azure.azcollection.azure_rm կամ google.cloud.gcp_compute, հարցում են անում պրովայդերին և խմբեր կառուցում tag-երից, ուստի role=web tag-ով սերվերը ավտոմատ հայտնվում է web խմբում։ Ansible-ը laptop-ներից աշխատեցնելու փոխարեն որպես ընդհանուր ծառայություն աշխատեցնելու համար AWX-ը (Red Hat Ansible Automation Platform-ի open-source upstream-ը) տրամադրում է վեբ UI, role-based մուտք, credentials-ի պահեստ, ժամանակացույցեր, API և աուդիտի լոգեր։ Execution Environment-ները container image-ներ են, որոնք փաթեթավորում են ansible-core-ը, collection-ները և Python dependency-ները, build են արվում ansible-builder-ով և աշխատեցվում ansible-navigator-ով կամ AWX-ով։ Դրանք լուծում են դասական «իմ control node-ի վրա աշխատում է» խնդիրը՝ ավտոմատացման runtime-ը դարձնելով նույնքան վերարտադրելի, որքան իր deploy արած հավելվածների image-ները։