అన్సిబుల్‌లోని వేరియబుల్స్‌కు సిస్టమ్ విధానం

ansible devops కోడ్‌స్టైల్

హే! నా పేరు డెనిస్ కల్యుజ్నీ నేను డెవలప్‌మెంట్ ప్రాసెస్ ఆటోమేషన్ విభాగంలో ఇంజనీర్‌గా పని చేస్తున్నాను. ప్రతిరోజూ, వందలాది ప్రచార సర్వర్‌లకు కొత్త అప్లికేషన్ బిల్డ్‌లు అందుబాటులోకి వస్తాయి. మరియు ఈ ఆర్టికల్‌లో, ఈ ప్రయోజనాల కోసం అన్సిబుల్‌ని ఉపయోగించిన నా అనుభవాన్ని నేను పంచుకుంటాను.

ఈ గైడ్ విస్తరణలో వేరియబుల్‌లను నిర్వహించడానికి ఒక మార్గాన్ని అందిస్తుంది. ఈ గైడ్ ఇప్పటికే వారి ప్లేబుక్‌లలో పాత్రలను ఉపయోగించే మరియు చదివే వారి కోసం రూపొందించబడింది ఉత్తమ పద్ధతులుకానీ ఇలాంటి సమస్యలలో నడుస్తోంది:

• కోడ్‌లో వేరియబుల్‌ని కనుగొన్న తర్వాత, దాని బాధ్యత ఏమిటో వెంటనే అర్థం చేసుకోవడం అసాధ్యం;
• అనేక పాత్రలు ఉన్నాయి మరియు వేరియబుల్స్ ఒక విలువతో అనుబంధించబడాలి, కానీ అది పని చేయదు;
• మీ ప్లేబుక్స్‌లోని వేరియబుల్స్ యొక్క లాజిక్ ఎలా పనిచేస్తుందో ఇతరులకు వివరించడంలో ఇబ్బంది ఉంది

మేము మా కంపెనీలోని ప్రాజెక్ట్‌లలో ఈ సమస్యలను ఎదుర్కొన్నాము, దీని ఫలితంగా మేము మా ప్లేబుక్‌లలో వేరియబుల్స్ ఫార్మాటింగ్ నియమాలకు వచ్చాము, ఇది కొంతవరకు ఈ సమస్యలను పరిష్కరించింది.

పాత్రలలో వేరియబుల్స్

రోల్ అనేది ఒక ప్రత్యేక డిప్లాయ్‌మెంట్ సిస్టమ్ ఆబ్జెక్ట్. సిస్టమ్ యొక్క ఏదైనా వస్తువు వలె, మిగిలిన సిస్టమ్‌తో పరస్పర చర్య చేయడానికి ఇది తప్పనిసరిగా ఇంటర్‌ఫేస్‌ను కలిగి ఉండాలి. రోల్ వేరియబుల్స్ అటువంటి ఇంటర్‌ఫేస్.

ఉదాహరణకు, పాత్రను తీసుకోండి api, ఇది సర్వర్‌లో జావా అప్లికేషన్‌ను ఇన్‌స్టాల్ చేస్తుంది. దీనికి ఏ వేరియబుల్స్ ఉన్నాయి?

రోల్ వేరియబుల్స్ రకం ద్వారా 2 రకాలుగా విభజించవచ్చు:

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

వేరియబుల్ లక్షణాలు పాత్ర యొక్క ప్రవర్తనను నిర్వచించే వేరియబుల్స్.

ప్రశ్న వేరియబుల్స్ పాత్రకు వెలుపలి వనరులను సూచించడానికి ఉపయోగించే వేరియబుల్స్.

వేరియబుల్ శ్రోతలు క్వెరీ వేరియబుల్స్‌ను రూపొందించడానికి ఉపయోగించే వేరియబుల్స్.

మరోవైపు, 1a, 2a, 2b పర్యావరణంపై ఆధారపడని వేరియబుల్స్ (ఇనుము, బాహ్య వనరులు మొదలైనవి) మరియు డిఫాల్ట్ పాత్రలో డిఫాల్ట్ విలువలతో నింపవచ్చు. అయినప్పటికీ, 1.b మరియు 2.c వంటి వేరియబుల్స్ 'ఉదాహరణ' కాకుండా ఇతర విలువలతో నింపబడవు, ఎందుకంటే అవి పర్యావరణాన్ని బట్టి స్టాండ్ నుండి స్టాండ్‌కు మారుతాయి.

కోడ్ శైలి

• వేరియబుల్ పేరు తప్పనిసరిగా పాత్ర పేరుతో ప్రారంభం కావాలి. ఇది భవిష్యత్తులో వేరియబుల్ ఏ పాత్ర నుండి మరియు దాని బాధ్యత ఏమిటో గుర్తించడం సులభం చేస్తుంది.
• పాత్రలలో వేరియబుల్‌లను ఉపయోగిస్తున్నప్పుడు, మీరు తప్పనిసరిగా ఎన్‌క్యాప్సులేషన్ సూత్రాన్ని అనుసరించాలి మరియు పాత్రలో లేదా ప్రస్తుత పాత్రపై ఆధారపడిన పాత్రలలో నిర్వచించబడిన వేరియబుల్‌లను ఉపయోగించాలి.

• వేరియబుల్స్ కోసం నిఘంటువులను ఉపయోగించడం మానుకోండి. డిక్షనరీలోని వ్యక్తిగత విలువలను సౌకర్యవంతంగా భర్తీ చేయడానికి Ansible మిమ్మల్ని అనుమతించదు.

  చెడ్డ వేరియబుల్ యొక్క ఉదాహరణ:

  myrole_user:
      login: admin
      password: admin

  ఇక్కడ, లాగిన్ అనేది మధ్యస్థ వేరియబుల్, మరియు పాస్‌వర్డ్ డిపెండెంట్ వేరియబుల్. కానీ
  అవి నిఘంటువుగా మిళితం చేయబడినందున, మీరు దానిని పూర్తిగా పేర్కొనవలసి ఉంటుంది
  ఎల్లప్పుడూ. ఇది చాలా అసౌకర్యంగా ఉంది. ఈ విధంగా ఉత్తమం:

  myrole_user_login: admin
  myrole_user_password: admin

విస్తరణ ప్లేబుక్‌లలో వేరియబుల్స్

డిప్లాయ్‌మెంట్ ప్లేబుక్‌ను కంపైల్ చేస్తున్నప్పుడు (ఇకపై ప్లేబుక్‌గా సూచిస్తారు), మేము దానిని ప్రత్యేక రిపోజిటరీలో ఉంచాలనే నియమానికి కట్టుబడి ఉంటాము. పాత్రల వలె: ప్రతి దాని స్వంత git రిపోజిటరీలో. ఇది పాత్రలు మరియు ప్లేబుక్ విస్తరణ వ్యవస్థ యొక్క విభిన్న స్వతంత్ర వస్తువులు అని గ్రహించడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు ఒక వస్తువులో మార్పులు మరొకదాని ఆపరేషన్‌ను ప్రభావితం చేయకూడదు. వేరియబుల్స్ యొక్క డిఫాల్ట్ విలువలను మార్చడం ద్వారా ఇది సాధించబడుతుంది.

ప్లేబుక్‌ను కంపైల్ చేసేటప్పుడు, సంగ్రహంగా చెప్పాలంటే, రోల్ వేరియబుల్స్ యొక్క డిఫాల్ట్ విలువలను రెండు ప్రదేశాలలో భర్తీ చేయడం సాధ్యపడుతుంది: ప్లేబుక్ వేరియబుల్స్ మరియు ఇన్వెంటరీ వేరియబుల్స్‌లో.

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - వేరియబుల్స్ మరియు వాల్ట్‌లు

తేడా ఏమిటంటే ప్లేబుక్ వేరియబుల్స్‌తో అదే స్థాయిలో ఉన్న ప్లేబుక్‌లను కాల్ చేస్తున్నప్పుడు ఎల్లప్పుడూ ఉపయోగించబడతాయి. పర్యావరణంపై ఆధారపడని వేరియబుల్స్ యొక్క డిఫాల్ట్ విలువలను మార్చడానికి ఈ వేరియబుల్స్ గొప్పవి అని దీని అర్థం. దీనికి విరుద్ధంగా, ఇన్వెంటరీ వేరియబుల్స్ నిర్దిష్ట వాతావరణం కోసం మాత్రమే ఉపయోగించబడతాయి, ఇది పర్యావరణ-నిర్దిష్ట వేరియబుల్స్‌కు అనువైనది.

ప్లేబుక్ వేరియబుల్స్‌లో మొదట వేరియబుల్స్‌ను పునర్నిర్వచించటానికి వేరియబుల్ ప్రాధాన్యత మిమ్మల్ని అనుమతించదని గమనించడం ముఖ్యం, ఆపై అదే ఇన్వెంటరీలో విడిగా.

దీని అర్థం ఇప్పటికే ఈ దశలో మీరు వేరియబుల్ పర్యావరణంపై ఆధారపడి ఉందో లేదో నిర్ణయించుకోవాలి మరియు దానిని సరైన స్థలంలో ఉంచాలి.

ఉదాహరణకు, ఒక ప్రాజెక్ట్‌లో, SSLని ఎనేబుల్ చేయడానికి బాధ్యత వహించే వేరియబుల్ చాలా కాలం పాటు పర్యావరణంపై ఆధారపడి ఉంటుంది, ఎందుకంటే స్టాండ్‌లలో ఒకదానిలో మా నియంత్రణకు మించిన కారణాల వల్ల మేము SSLని ప్రారంభించలేము. మేము ఈ సమస్యను పరిష్కరించిన తర్వాత, ఇది మీడియం స్వతంత్రంగా మారింది మరియు ప్లేబుక్ వేరియబుల్స్‌కు తరలించబడింది.

గుంపుల కోసం ప్రాపర్టీ వేరియబుల్స్

వేరొక జావా అప్లికేషన్‌తో, కానీ విభిన్న సెట్టింగ్‌లతో 1 సర్వర్‌ల సమూహాలను జోడించడం ద్వారా మూర్తి 2లో మా మోడల్‌ను విస్తరింపజేద్దాం.

ఈ సందర్భంలో ప్లేబుక్ ఎలా ఉంటుందో ఊహించండి:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

మేము ప్లేబుక్‌లో మూడు సమూహాలను కలిగి ఉన్నాము, కాబట్టి group_vars ఇన్వెంటరీ వేరియబుల్స్ మరియు ప్లేబుక్ వేరియబుల్స్‌లో ఒకేసారి అనేక సమూహ ఫైల్‌లను సృష్టించాలని సిఫార్సు చేయబడింది. ఈ సందర్భంలో ఒక సమూహ ఫైల్ ప్లేబుక్‌లోని మీ అప్లికేషన్‌లోని ఒక భాగం యొక్క వివరణ. మీరు ప్లేబుక్ వేరియబుల్స్‌లో సమూహ ఫైల్‌ను తెరిచినప్పుడు, సమూహానికి కేటాయించిన పాత్రల యొక్క డిఫాల్ట్ ప్రవర్తన నుండి అన్ని తేడాలను మీరు వెంటనే చూస్తారు. ఇన్వెంటరీ వేరియబుల్స్‌లో: బూత్ నుండి బూత్ వరకు సమూహ ప్రవర్తనలో తేడాలు.

కోడ్ శైలి

• host_vars వేరియబుల్స్‌ని అస్సలు ఉపయోగించకూడదని ప్రయత్నించండి, ఎందుకంటే అవి సిస్టమ్‌ను వివరించలేదు, కానీ ఒక ప్రత్యేక సందర్భంలో మాత్రమే, దీర్ఘకాలంలో ప్రశ్నలకు దారి తీస్తుంది: "ఈ హోస్ట్ మిగిలిన వాటి నుండి ఎందుకు భిన్నంగా ఉంటుంది?", దీనికి సమాధానం కనుగొనడం ఎల్లప్పుడూ సులభం కాదు.

లింక్ వేరియబుల్స్

అయితే, అది ప్రాపర్టీ వేరియబుల్స్ గురించి, కానీ లింక్ వేరియబుల్స్ గురించి ఏమిటి?
వారి వ్యత్యాసం ఏమిటంటే వారు వేర్వేరు సమూహాలలో ఒకే విలువను కలిగి ఉండాలి.

ప్రారంభంలో ఉంది ఆలోచన రూపం యొక్క భయంకరమైన నిర్మాణాన్ని ఉపయోగించండి:
hostvars[groups['bbauth'][0]]['auth_bind_port'], కానీ అది వెంటనే వదిలివేయబడింది
ఎందుకంటే దానిలో లోపాలు ఉన్నాయి. మొదటిది, స్థూలత. రెండవది, సమూహంలోని నిర్దిష్ట హోస్ట్‌పై ఆధారపడటం. మూడవదిగా, మేము నిర్వచించబడని వేరియబుల్ ఎర్రర్‌ను పొందకూడదనుకుంటే, విస్తరణను ప్రారంభించే ముందు అన్ని హోస్ట్‌ల నుండి వాస్తవాలను సేకరించడం అవసరం.

ఫలితంగా, లింక్ వేరియబుల్స్ ఉపయోగించాలని నిర్ణయించారు.

లింక్ వేరియబుల్స్ ప్లేబుక్‌కు చెందిన వేరియబుల్స్ మరియు సిస్టమ్ ఆబ్జెక్ట్‌లను లింక్ చేయడానికి అవసరం.

లింక్ వేరియబుల్స్ సాధారణ సిస్టమ్ వేరియబుల్స్‌లో ఉంటాయి group_vars/all/vars మరియు ప్రతి సమూహం నుండి అన్ని వినేవారి వేరియబుల్‌లను తీసివేయడం ద్వారా మరియు శ్రోతని తొలగించిన సమూహం పేరును వేరియబుల్ ప్రారంభానికి జోడించడం ద్వారా ఏర్పడతాయి.

అందువలన, పేర్ల యొక్క ఏకరూపత మరియు ఖండన నిర్ధారిస్తుంది.

పై ఉదాహరణ నుండి వేరియబుల్స్ బైండ్ చేయడానికి ప్రయత్నిద్దాం:

మనకు ఒకదానికొకటి ఆధారపడే వేరియబుల్స్ ఉన్నాయని ఊహించండి:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

సాధారణ వేరియబుల్స్‌లో ఉంచుదాం group_vars/all/vars అన్ని శ్రోతలు, మరియు పేరుకు సమూహం యొక్క పేరును జోడించండి:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

ఇప్పుడు, కనెక్టర్ విలువను మార్చడం ద్వారా, అభ్యర్థన అదే పోర్ట్‌కు వెళ్తుందని మేము ఖచ్చితంగా అనుకుంటున్నాము.

కోడ్ శైలి

• సిస్టమ్‌లోని పాత్రలు మరియు సమూహాలు వేర్వేరు వస్తువులు కాబట్టి, మీరు వాటికి వేర్వేరు పేర్లను కలిగి ఉండాలి, అప్పుడు లింక్ వేరియబుల్స్ అవి నిర్దిష్ట సర్వర్‌ల సమూహానికి చెందినవని ఖచ్చితంగా చూపుతాయి మరియు సిస్టమ్‌లోని పాత్రకు కాదు.

పర్యావరణ ఫైళ్లు

పాత్రలు పర్యావరణం నుండి పర్యావరణానికి భిన్నమైన ఫైల్‌లను ఉపయోగించవచ్చు.

SSL ప్రమాణపత్రాలు అటువంటి ఫైళ్ళకు ఉదాహరణ. వాటిని వచనంగా నిల్వ చేయండి
వేరియబుల్‌లో చాలా సౌకర్యవంతంగా లేదు. కానీ వాటికి మార్గాన్ని వేరియబుల్ లోపల నిల్వ చేయడం సౌకర్యంగా ఉంటుంది.

ఉదాహరణకు, మేము వేరియబుల్ ఉపయోగిస్తాము api_ssl_key_file: "/path/to/file".

కీ సర్టిఫికేట్ పర్యావరణం నుండి పర్యావరణానికి మారుతుందని స్పష్టంగా ఉన్నందున, ఇది పర్యావరణం-ఆధారిత వేరియబుల్, అంటే ఇది ఫైల్‌లో ఉండాలి
group_vars/myapi/vars వేరియబుల్స్ ఇన్వెంటరీ, మరియు 'ఉదాహరణకు' విలువను కలిగి ఉంటుంది.

ఈ సందర్భంలో అత్యంత అనుకూలమైన మార్గం మార్గం వెంట ప్లేబుక్ రిపోజిటరీలో కీ ఫైల్ను ఉంచడం
files/prod/certs/myapi.key, అప్పుడు వేరియబుల్ విలువ ఇలా ఉంటుంది:
api_ssl_key_file: "prod/certs/myapi.key". ఒక నిర్దిష్ట స్టాండ్‌లో సిస్టమ్‌ను అమలు చేయడానికి బాధ్యత వహించే వ్యక్తులు తమ ఫైల్‌లను నిల్వ చేయడానికి రిపోజిటరీలో వారి స్వంత ప్రత్యేక స్థలాన్ని కలిగి ఉండటం సౌలభ్యం. అదే సమయంలో, సర్టిఫికేట్‌లు మరొక సిస్టమ్ ద్వారా సరఫరా చేయబడితే, సర్వర్‌లోని ప్రమాణపత్రానికి సంపూర్ణ మార్గాన్ని పేర్కొనడం సాధ్యమవుతుంది.

ఒకే వాతావరణంలో బహుళ నిలుస్తుంది

తక్కువ వ్యత్యాసాలతో ఒకే వాతావరణంలో అనేక దాదాపు ఒకే విధమైన స్టాండ్‌లను అమలు చేయవలసిన అవసరం తరచుగా ఉంటుంది. ఈ సందర్భంలో, మేము పర్యావరణం-ఆధారిత వేరియబుల్స్‌ను ఈ వాతావరణంలో మారని వాటికి మరియు మారే వాటికి విభజిస్తాము. మరియు మేము రెండోదాన్ని నేరుగా ఇన్వెంటరీ ఫైల్‌లలోకి తీసుకుంటాము. ఈ తారుమారు తర్వాత, పర్యావరణ డైరెక్టరీలో నేరుగా మరొక జాబితాను సృష్టించడం సాధ్యమవుతుంది.

ఇది group_vars ఇన్వెంటరీని మళ్లీ ఉపయోగిస్తుంది మరియు దాని కోసం నేరుగా కొన్ని వేరియబుల్స్‌ని పునర్నిర్వచించగలదు.

విస్తరణ ప్రాజెక్ట్ కోసం చివరి డైరెక్టరీ నిర్మాణం:

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

సంక్షిప్తం

వ్యాసానికి అనుగుణంగా వేరియబుల్స్‌ను ఆర్గనైజ్ చేసిన తర్వాత: వేరియబుల్స్‌తో ఉన్న ప్రతి ఫైల్ ఒక నిర్దిష్ట పనికి బాధ్యత వహిస్తుంది. మరియు ఫైల్‌కు నిర్దిష్ట పనులు ఉన్నందున, ప్రతి ఫైల్ యొక్క ఖచ్చితత్వానికి బాధ్యత వహించే వ్యక్తిని కేటాయించడం సాధ్యమైంది. ఉదాహరణకు, ప్లేబుక్ వేరియబుల్స్‌ను సరిగ్గా పూరించడానికి సిస్టమ్ డిప్లాయ్‌మెంట్ డెవలపర్ బాధ్యత వహిస్తాడు, అయితే ఇన్వెంటరీలో వివరించబడిన అడ్మినిస్ట్రేటర్, వేరియబుల్స్ ఇన్వెంటరీని పూరించడానికి నేరుగా బాధ్యత వహిస్తాడు.

పాత్రలు వారి స్వంత ఇంటర్‌ఫేస్‌తో స్వీయ-నియంత్రణ అభివృద్ధి యూనిట్‌గా మారాయి, రోల్ డెవలపర్‌ని సిస్టమ్‌కు సరిపోయేలా పాత్రను రూపొందించడం కంటే లక్షణాలను అభివృద్ధి చేయడానికి అనుమతిస్తుంది. ప్రచారంలో అన్ని సిస్టమ్‌లకు ఉమ్మడి పాత్రలకు ఈ సమస్య ప్రత్యేకంగా వర్తిస్తుంది.

సిస్టమ్ నిర్వాహకులు ఇకపై విస్తరణ కోడ్‌ను అర్థం చేసుకోవలసిన అవసరం లేదు. విజయవంతమైన విస్తరణ కోసం వారికి కావలసిందల్లా ఎన్విరాన్‌మెంట్ వేరియబుల్స్ ఫైల్‌లను పూరించడం.

సాహిత్యం

1. డాక్యుమెంటేషన్

రచయిత

కల్యుజ్నీ డెనిస్ అలెగ్జాండ్రోవిచ్

మూలం: www.habr.com