Ansible: კონფიგურაცია და სისულელე

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Ansible არის დეკლარაციული კონფიგურაციის და ორკესტრაციის ინსტრუმენტი, რომელიც იდეალურია მასპინძელთა/მასპინძელთა, სერვისებისა და პროგრამების განმეორებითი პარამეტრისთვის, როდესაც ინფრასტრუქტურა უკვე შეიქმნა (Terraform/IaC) და თქვენ უნდა „გააცოცხლოთ“ გარემო: დაამონტაჟეთ პაკეტები, განათავსეთ განთავისუფლება, გადააკეთეთ შაბლონები, გადატვირთეთ მომსახურება doWoWOOOOWEEAAAAA- ს გარეშე. წარმატების გასაღები: მოდულური სტრუქტურა (როლები/კოლექციები), მკაცრი იდემპოტენტობა, საიდუმლო (Vault), დინამიური აღჭურვილობა, ტესტირება და GitOps დისციპლინა.

როდესაც Ansible შესაფერისია (და როგორ ერწყმის იგი Terraform- ს)

Terraform - ქმნის რესურსებს (VPC, მტევანი, BD).
Ansible - კონფიგურაცია OS/PO, ატვირთავს ვერსიებს, მართავს მიგრაციას, მართავს ფაილებს და სერვისებს.
თაიგული: Terraform აჩვენებს 'inventory '/IP/საიდუმლოებებს არტეფაქტებში, Ansible მათ კითხულობს CD ეტაპზე.

საცავის სტრუქტურა (რეკომენდებული შაბლონი)


ansible/
inventories/
prod/
inventory. ini # or inventory. yaml group_vars/
all. yml web. yml db. yml host_vars/
web-01. yml stage/
...
roles/
webapp/
defaults/main. yml vars/main. yml tasks/main. yml handlers/main. yml templates/.j2 files/
meta/main. yml hardening/
...
playbooks/
site. yml deploy_webapp. yml hardening. yml collections/requirements. yml ansible. cfg

ansible. cfg (მინიმალური):

ini
[defaults]
inventory = inventories/stage/inventory. ini stdout_callback = yaml callbacks_enabled = timer, profile_tasks interpreter_python = auto retry_files_enabled = False forks = 25 host_key_checking = True

ინვენტარი: სტატიკური და დინამიური

სტატიკური (ini):

ini
[web]
web-01 ansible_host=10. 0. 1. 10 web-02 ansible_host=10. 0. 1. 11

[db]
db-01 ansible_host=10. 0. 2. 10

[all:vars]
ansible_user=ansible ansible_ssh_common_args='-o ProxyJump=bastion@1. 2. 3. 4'

დინამიური

გამოიყენეთ ღრუბლების პლაგინები (ან საკუთარი სკრიპტი), რათა მასპინძლები ჭდეებში გაიყვანოთ. გარემოს ცვლადი/ჭდეები 'ჯგუფის _ vars'.

როლები და კოლექციები

როლი = დამოუკიდებელი გამოყენების მოდული (დავალებები, ფაილები, შაბლონები, ჰენდლერები).
კოლექციები - როლების/დანამატების/მოდულების ერთობლიობა. ჩაწერეთ ვერსიის უკანა ნაწილები 'collections/requirements. yml`.

yaml collections/requirements. yml collections:
- name: community. general version: ">=8. 0. 0,<9. 0. 0"
- name: ansible. posix

Playbooks: idempotent სცენარები

საერთო პლეიბუკის მაგალითი:

yaml playbooks/site. yml
- hosts: all gather_facts: true become: true roles:
- hardening

- hosts: web become: true roles:
- webapp

'webapp- ის' როლი (ფრაგმენტები):

yaml roles/webapp/tasks/main. yml
- name: Install packages:
name: ["nginx", "python3-venv"]
state: present

- name: Template configuration template:
src: nginx. conf. j2 dest: /etc/nginx/nginx. conf mode: "0644"
notify: Restart nginx

- name: unarchive artifact deploy:
src: "{{ webapp_package_url }}"  # артефакт из CI dest: /opt/webapp remote_src: true creates: /opt/webapp/current

- name: Link to the current version of file:
src: "/opt/webapp/releases/{{ release_id }}"
dest: /opt/webapp/current state: link notify: Reload webapp

ჰენდლერები:

yaml roles/webapp/handlers/main. yml
- name: Restart nginx service: { name: nginx, state: restarted }

- name: Reload webapp systemd: { name: webapp, state: reloaded, daemon_reload: true }

Jinja2 შაბლონები და ცვლადი

შეინახეთ ნაგულისხმევი ცვლადები 'defaults/main. yml ', მგრძნობიარე - Vault- ში.
გამოიყენეთ ფილტრები ('| to _ nice _ yaml', '| b64encode', '| default') და პირობები 'when'.

მაგალითი 'nginx. conf. j2`:

jinja2 worker_processes auto;
http {
server {
listen 80;
server_name {{ inventory_hostname }};
location / {
proxy_pass http://127. 0. 0. 1:{{ webapp_port }};
}
}
}

საიდუმლოებები: Ansible Vault და საიდუმლოების მენეჯერები

ცვლადის ფაილების დაშიფვრის Vault ('group _ vars/all. vault. yml`).
უმჯობესია წაიკითხოთ საიდუმლოებები გარე მენეჯერებისგან (KMS/Secrets Manager/SSM) შესაბამისი მოდულების საშუალებით და შეინახოთ მხოლოდ ბმულები/ARN Vault- ში.

დაშიფრული ფაილი (სტრუქტურის მაგალითი):

yaml group_vars/all. vault. yml (ansible-vault encrypted)
webapp_db_password: "..."
jwt_signing_key: "..."

რეკომენდაციები:

გაზიარეთ წვდომა: დეველოპერები ხედავენ dev/stage, prod - მხოლოდ CI.
ჩართეთ საიდუმლოების როტაცია და წვდომის აუდიტი.

Idempotence და სწორი ცვლილებები

გამოიყენეთ მოდულები ('package', 'user', 'lineinfile', 'template', 'systemd') ნაცვლად 'shell/command'.
გააფორმეთ „ხმაურიანი“ დავალებები „ხმაურიანი _ when: false“, თუ ისინი არაფერს შეცვლიან.
შეინარჩუნეთ check mode ('-check') და diff როლებისთვის.
არასტაბილური დავალებებისთვის: 'retries', 'delay', 'until'.

მაგალითი:

yaml
- name: Wait for HTTP uri availability:
url: "http://localhost/health"
status_code: 200 register: health retries: 10 delay: 5 until: health. status == 200

პროდუქტიულობა: დიდი მეურნეობები და მწვერვალები

forks: აიღეთ პარალელიზმი (სიფრთხილით: ნუ გადაიტანთ მიზანს).
სტრატეგია = უფასო - შეასრულეთ დავალებები მეზობლების მოლოდინის გარეშე.
pipelining = True в `ansible. cfg 'ამცირებს RTT.
gather _ facts: false, სადაც ფაქტები არ არის საჭირო.
async/poll გრძელი ოპერაციებისთვის; throtle/serial deploy ტალღებისთვის.
delegate _ to და run _ once ერთჯერადი მოქმედებებისთვის (მაგალითად, BD მიგრაცია).

ნულოვანი დატვირთვის ნიმუშები

Rolling dead (თითო 20%)

yaml
- hosts: web serial: "20%"
max_fail_percentage: 10 roles: [webapp]

Canary

შეამოწმეთ playbuk '-limit web-canary' (ჯგუფის ქვესათაური), შეამოწმეთ მეტრიკა, შემდეგ გადაიტანეთ მთელ ჯგუფში.

Blue-Green

მასპინძელთა ორი ჯგუფი 'web _ blue' და 'web _ green'; Playbook- ით მოამზადეთ ახალი ტალღა, შემდეგ გადართეთ ტრეფიკი (DNS/LB) ამოცანა 'კომუნიკაცია. general. თქვენი დაბალანსების affiliate _ lb '/API.

უსაფრთხოება და უბედურება

hardening როლი: SSH პოლიტიკა, ბანერები, 'sudo' NOPASSWD- ის გარეშე, ფეიერვერკი, აუდიტი/rsyslog, დრო-NTP, 'fail2ban'.
ჩართეთ SELinux/AppARmor, მართეთ პოლიტიკოსები მოდულების საშუალებით.
სარდაფი: შეზღუდეთ SSH მიზნები მხოლოდ jump-host- ის საშუალებით (იხ. 'ProxyJump').
მინიმუმამდე დაიყვანეთ 'become: ნამდვილი'; შეადგინეთ RBAC ინვენტარის დონეზე (რომელსაც შეუძლია დაიწყოს რომელი playbucks).

Windows და ქსელის აპარატურა

Windows: 'win _' მოდულები, WinRM კავშირი, PowerShell სკრიპტები - როგორც ბოლო არგუმენტი.
ქსელი: 'ქსელი _ cli '/' httpapi', მოდულები Cisco/Juniper/F5; ატომურობა 'save _ when: changed' საშუალებით.

ტესტირება და ხარისხი

ansible-lint + yamllint в CI.
მოლეკული: როლების ადგილობრივი/კონტეინერის ტესტები, იდემპოტენტურობის შემოწმება (ორმაგი პროგონი უცვლელი).
ქვიშის ყუთი: ცალკეული დროებითი ინვენტარი/VM სურათები.

მაგალითი Molecule (ფრაგმენტი):

yaml provisioner:
name: ansible verifier:
name: ansible scenario:
name: default

ინტეგრაცია CI/CD და GitOps

ტიპიური pipline:

1. Lint → Syntax check → Molecule.

2. პროგრამის არტეფაქტების მშენებლობა.

3. Deploy: `ansible-playbook -i inventories/prod site. yml --limit web --tags deploy`.

4. რეპორტი შეცვლილი მასპინძლების შესახებ, ლოგოების არტეფაქტი.

ნაბიჯის მაგალითი (კონცეფცია):

bash ansible-galaxy collection install -r collections/requirements. yml ansible-lint ansible-playbook playbooks/deploy_webapp. yml \
-i inventories/prod/inventory. ini \
-e release_id=${GIT_SHA} --diff

დაკვირვება და აუდიტი

დააკავშირეთ callback მოდულები (json/yaml/timer/profile _ tasks) - მოხსენებები დროისა და ცვლილებების შესახებ.
შეინახეთ პლეიბუკების ლოგოები ცენტრალიზებულ საცავში.
მიუთითეთ დავალებები 'tags:' შერჩევის დაწყებისა და გამოძიების დაჩქარების მიზნით.

ხშირი რეცეპტები iGaming- ისთვის

Web/API noda: Nginx + systemd ერთეული, ჯანმრთელობის შემოწმებები, მენეჯერის საიდუმლოებები, roll-restart.
თამაშის სერვისები: კონფიგურაციის შაბლონები რეგიონებში/ტენანტებში 'group _ vars' საშუალებით.
გადახდის კონექტორები: მკაცრი permichans გასაღებებზე, გადატვირთვა notify- ზე, endpoint- ის პოსტ - ტესტირება.
ETL ჯობი: CronJob სკრიპტების განთავსება c 'cron' მოდულით, idempotent lock ფაილი.
მონიტორინგი: აგენტების დაყენება (node _ exporter/otelcol), მანქანის რეგისტრაცია მონიტორინგში.

ანტიპატერები

'shell/command- ის' გამოყენება, სადაც არის მოდული.
Playbooks 'handlers- ის გარეშე არის დამატებითი შეზღუდვები და მომსახურების ტრიალება.
საიდუმლოებების შენახვა ღია 'ჯგუფში _ vars'.
არარსებობა 'serial '/' max _ fail _ percentage' prod ტალღების გამო.
გლობალური 'gather _ facts: ნამდვილი' და 'become: ნამდვილი "საჭიროების გარეშე.
როლები Molecule ტესტების გარეშე და '-check' მხარდაჭერის გარეშე.
გრძელი ბრძანებები 'async/poll' გარეშე, რომლებიც ბლოკავს მთელ ტალღას.

ჩეკის განხორციელების სია

1. დააკონკრეტა საცავის ჩარჩო და naming კონვენცია.
2. ეს დინამიური ინვენტარი და ბასტინგი.
3. დაიწყეთ როლები (webapp/hardening/monitoring) და კოლექციების ვერსია.
4. ჩართეთ Vault ან/და ინტეგრაცია საიდუმლოების მენეჯერთან.
5. უზრუნველყოს idempotence, '-check/-diff', handlers და ჭდეები.
6. დააკავშიროთ ansible-lint, yamlint, Molecule CI- ში.
7. აღწერეთ დეფლორის ნიმუში (rolling/canary/blue-green) და limites 'serial'.
8. დაამატეთ callback მოდულები, ლოგოების შეგროვება, ანგარიში ცვლილებების შესახებ.
9. ინციდენტების დროს runbook და მოქმედებების დოკუმენტაცია.
10. რეგულარულად ჩაატარეთ თამაშის დღე: SSH კლდე, მოდის ვარდნა, ვერსიის დაბრუნება.

შედეგები

Ansible ხურავს „ბოლო მილის“ შექმნას ინფრასტრუქტურასა და სამუშაო გაყიდვას შორის: კონფიგურაციებისა და გამოშვებების სწრაფი, უსაფრთხო და პროგნოზირებადი ცვლილებები. მისი როლით, როგორც ხელახალი გამოყენების მინიმალური ერთეული, დინამიური აღჭურვილობა, საიდუმლოებებთან სწორი მუშაობა და ნულოვანი დისტანციის დამოწმებული ნიმუშები, Ansible ეხმარება iGaming გუნდებს შეამცირონ Time-to-Deploy, შეამცირონ ღამის ინციდენტების რაოდენობა და შეინარჩუნონ p99 SLO დონეზე.