🥇Ansible இல் மாறிகளுக்கு முறையான அணுகுமுறை

ansible devops codestyle

ஏய்! என் பெயர் டெனிஸ் கல்யுஸ்னி நான் டெவலப்மென்ட் பிராசஸ் ஆட்டோமேஷன் பிரிவில் பொறியாளராகப் பணிபுரிகிறேன். ஒவ்வொரு நாளும், நூற்றுக்கணக்கான பிரச்சார சேவையகங்களில் புதிய பயன்பாட்டு உருவாக்கங்கள் வெளியிடப்படுகின்றன. இந்த நோக்கங்களுக்காக Ansible ஐப் பயன்படுத்திய எனது அனுபவத்தை இந்த கட்டுரையில் பகிர்ந்து கொள்கிறேன்.

இந்த வழிகாட்டி வரிசைப்படுத்தலில் மாறிகளை ஒழுங்கமைப்பதற்கான வழியை வழங்குகிறது. இந்த வழிகாட்டி ஏற்கனவே தங்கள் நாடக புத்தகங்களில் பாத்திரங்களைப் பயன்படுத்துபவர்களுக்காகவும் படித்தவர்களுக்காகவும் வடிவமைக்கப்பட்டுள்ளது சிறந்த நடைமுறைகள், ஆனால் இதே போன்ற சிக்கல்களை எதிர்கொள்கிறது:

குறியீட்டில் ஒரு மாறியைக் கண்டறிந்த பிறகு, அது என்ன பொறுப்பு என்பதை உடனடியாக புரிந்து கொள்ள முடியாது;
பல பாத்திரங்கள் உள்ளன, மற்றும் மாறிகள் ஒரு மதிப்புடன் இணைக்கப்பட வேண்டும், ஆனால் அது வேலை செய்யாது;
உங்கள் பிளேபுக்குகளில் உள்ள மாறிகளின் தர்க்கம் எவ்வாறு செயல்படுகிறது என்பதை மற்றவர்களுக்கு விளக்குவதில் சிரமம் உள்ளது

எங்கள் நிறுவனத்தில் உள்ள திட்டங்களில் இந்த சிக்கல்களை நாங்கள் சந்தித்தோம், இதன் விளைவாக எங்கள் பிளேபுக்குகளில் மாறிகளை வடிவமைப்பதற்கான விதிகளுக்கு வந்தோம், இது ஓரளவிற்கு இந்த சிக்கல்களைத் தீர்த்தது.

பாத்திரங்களில் மாறிகள்

ஒரு பங்கு என்பது வரிசைப்படுத்தல் அமைப்பின் ஒரு தனி பொருள். எந்தவொரு கணினி பொருளையும் போலவே, இது மற்ற கணினியுடன் தொடர்பு கொள்ள ஒரு இடைமுகத்தைக் கொண்டிருக்க வேண்டும். அத்தகைய இடைமுகம் பங்கு மாறிகள் ஆகும்.

உதாரணமாக, பாத்திரத்தை எடுத்துக் கொள்வோம் api, இது சர்வரில் ஜாவா பயன்பாட்டை நிறுவுகிறது. என்ன மாறிகள் இருக்கலாம்?

வகைக்கு ஏற்ப மாறி பாத்திரங்களை 2 வகைகளாகப் பிரிக்கலாம்:

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

மாறக்கூடிய பண்புகள் ஒரு பாத்திரத்தின் நடத்தையை தீர்மானிக்கும் மாறிகள்.

வினவல் மாறிகள் - இவை மாறிகள் ஆகும், அதன் மதிப்பு பாத்திரத்திற்கு வெளிப்புற வளங்களைக் குறிக்கப் பயன்படுகிறது.

மாறி கேட்பவர்கள் - இவை மாறிகள் ஆகும், அதன் மதிப்பு கோரிக்கை மாறிகளை உருவாக்க பயன்படுகிறது.

மறுபுறம், 1a, 2a, 2b ஆகியவை சுற்றுச்சூழலைச் சார்ந்து இல்லாத மாறிகள் (வன்பொருள், வெளிப்புற வளங்கள் போன்றவை) மற்றும் இயல்புநிலை பாத்திரத்தில் இயல்புநிலை மதிப்புகளால் நிரப்பப்படலாம். இருப்பினும், வகை 1.b மற்றும் 2.c இன் மாறிகளை 'எடுத்துக்காட்டு' தவிர வேறு மதிப்புகளுடன் நிரப்புவது சாத்தியமில்லை, ஏனெனில் அவை சூழலைப் பொறுத்து நிலையிலிருந்து ஸ்டாண்டிற்கு மாறும்.

குறியீடு நடை

மாறி பெயர் பங்கு பெயருடன் தொடங்க வேண்டும். இது எதிர்காலத்தில் மாறி என்ன பங்கு வகிக்கிறது மற்றும் அது எதற்காக பொறுப்பாகும் என்பதைக் கண்டுபிடிப்பதை எளிதாக்கும்.
பாத்திரங்களில் மாறிகளைப் பயன்படுத்தும் போது, நீங்கள் இணைத்தல் கொள்கையைப் பின்பற்றுவதை உறுதிசெய்ய வேண்டும் மற்றும் தற்போதைய பாத்திரத்தில் அல்லது தற்போதைய பாத்திரங்களில் வரையறுக்கப்பட்ட மாறிகளைப் பயன்படுத்த வேண்டும்.
மாறிகளுக்கு அகராதிகளைப் பயன்படுத்துவதைத் தவிர்க்கவும். ஒரு அகராதியில் தனிப்பட்ட மதிப்புகளை வசதியாக மேலெழுத அன்சிபிள் உங்களை அனுமதிக்காது.

மோசமான மாறியின் எடுத்துக்காட்டு:
```
myrole_user:
    login: admin
    password: admin
```
இங்கே உள்நுழைவு என்பது சார்பற்ற மாறி, கடவுச்சொல் என்பது சார்பு மாறி. ஆனாலும்
அவை ஒரு அகராதியாக இணைக்கப்பட்டுள்ளதால், நீங்கள் அதை முழுமையாகக் குறிப்பிட வேண்டும்
எப்போதும். இது மிகவும் சிரமமாக உள்ளது. இந்த வழியில் சிறந்தது:
```
myrole_user_login: admin
myrole_user_password: admin
```

வரிசைப்படுத்தல் விளையாட்டு புத்தகங்களில் மாறிகள்

வரிசைப்படுத்தல் பிளேபுக்கைத் தொகுக்கும்போது (இனிமேல் பிளேபுக் என குறிப்பிடப்படுகிறது), அதை ஒரு தனி களஞ்சியத்தில் வைக்க வேண்டும் என்ற விதியை நாங்கள் கடைபிடிக்கிறோம். பாத்திரங்களைப் போலவே: ஒவ்வொன்றும் அதன் சொந்த கிட் களஞ்சியத்தில். பாத்திரங்கள் மற்றும் பிளேபுக் ஆகியவை வரிசைப்படுத்தல் அமைப்பின் வெவ்வேறு சுயாதீனமான பொருள்கள் என்பதை இது புரிந்து கொள்ள உங்களை அனுமதிக்கிறது, மேலும் ஒரு பொருளில் ஏற்படும் மாற்றங்கள் மற்றொன்றின் செயல்பாட்டை பாதிக்கக்கூடாது. மாறிகளின் இயல்புநிலை மதிப்புகளை மாற்றுவதன் மூலம் இது அடையப்படுகிறது.

ஒரு பிளேபுக்கைத் தொகுக்கும்போது, சுருக்கமாக, பங்கு மாறிகளின் இயல்புநிலை மதிப்புகளை இரண்டு இடங்களில் மேலெழுத முடியும்: பிளேபுக் மாறிகள் மற்றும் சரக்கு மாறிகள்.

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

சுருக்கமாகக்

கட்டுரைக்கு ஏற்ப மாறிகளை ஒழுங்கமைத்த பிறகு: ஒவ்வொரு மாறி கோப்பும் ஒரு குறிப்பிட்ட பணிக்கு பொறுப்பாகும். கோப்பில் சில பணிகள் இருப்பதால், ஒவ்வொரு கோப்பின் சரியான தன்மைக்கும் பொறுப்பான ஒருவரை நியமிக்க முடியும். எடுத்துக்காட்டாக, பிளேபுக் மாறிகளை சரியாக நிரப்புவதற்கு கணினி வரிசைப்படுத்தலின் டெவலப்பர் பொறுப்பாவார், அதே நேரத்தில் சரக்குகளில் விவரிக்கப்பட்டுள்ள நிர்வாகி மாறிகளின் சரக்குகளை நிரப்புவதற்கு நேரடியாகப் பொறுப்பேற்கிறார்.

பாத்திரங்கள் அவற்றின் சொந்த இடைமுகத்துடன் அவற்றின் சொந்த மேம்பாட்டுப் பிரிவாக மாறியது, இது பாத்திரத்தை உருவாக்குபவரை கணினிக்கு ஏற்ப மாற்றுவதற்கு பதிலாக திறன்களை உருவாக்க அனுமதிக்கிறது. இந்தச் சிக்கல் குறிப்பாக பிரச்சாரத்தில் உள்ள அனைத்து அமைப்புகளுக்கும் பொதுவான பாத்திரங்களைப் பற்றியது.

கணினி நிர்வாகிகள் வரிசைப்படுத்தல் குறியீட்டைப் புரிந்து கொள்ள வேண்டியதில்லை. வெற்றிகரமான வரிசைப்படுத்தலுக்கு அவர்களுக்குத் தேவையானது சூழல் சார்ந்த மாறிகளின் கோப்புகளை நிரப்புவதுதான்.

இலக்கியம்

ஆவணங்கள்

ஆசிரியர்

கல்யுஸ்னி டெனிஸ் அலெக்ஸாண்ட்ரோவிச்

ஆதாரம்: www.habr.com

அன்சிபில் மாறிகளுக்கு கணினி அணுகுமுறை

பாத்திரங்களில் மாறிகள்

குறியீடு நடை

வரிசைப்படுத்தல் விளையாட்டு புத்தகங்களில் மாறிகள்

குழுக்களுக்கான சொத்து மாறிகள்

குறியீடு நடை

தொடர்பு மாறிகள்

குறியீடு நடை

சுற்றுச்சூழல் சார்ந்த கோப்புகள்

ஒரே சூழலில் பல நிலைகள்

வரிசைப்படுத்தல் திட்டத்திற்கான இறுதி அடைவு அமைப்பு:

சுருக்கமாகக்

இலக்கியம்

ஆசிரியர்

கருத்தைச் சேர் Отменить ответ