Ansible માં ચલ માટે સિસ્ટમ અભિગમ

જવાબી devops કોડસ્ટાઇલ

અરે! મારું નામ ડેનિસ કાલ્યુઝની હું વિકાસ પ્રક્રિયા ઓટોમેશન વિભાગમાં એન્જિનિયર તરીકે કામ કરું છું. દરરોજ, નવા એપ્લિકેશન બિલ્ડ્સને સેંકડો ઝુંબેશ સર્વર્સ પર રોલઆઉટ કરવામાં આવે છે. અને આ લેખમાં, હું આ હેતુઓ માટે Ansible નો ઉપયોગ કરવાનો મારો અનુભવ શેર કરું છું.

આ માર્ગદર્શિકા જમાવટમાં ચલોને ગોઠવવાની રીત પ્રદાન કરે છે. આ માર્ગદર્શિકા તે લોકો માટે રચાયેલ છે જેઓ પહેલેથી જ તેમની પ્લેબુકમાં ભૂમિકાઓનો ઉપયોગ કરે છે અને વાંચે છે શ્રેષ્ઠ વ્યવહારપરંતુ સમાન સમસ્યાઓનો સામનો કરવો પડે છે:

• કોડમાં ચલ મળ્યા પછી, તે શું માટે જવાબદાર છે તે તરત જ સમજવું અશક્ય છે;
• ત્યાં ઘણી ભૂમિકાઓ છે, અને ચલોને એક મૂલ્ય સાથે સાંકળવાની જરૂર છે, પરંતુ તે કામ કરતું નથી;
• તમારી પ્લેબુકમાં વેરીએબલ્સના તર્ક કેવી રીતે કાર્ય કરે છે તે અન્ય લોકોને સમજાવવામાં મુશ્કેલી આવી રહી છે

અમને અમારી કંપનીના પ્રોજેક્ટ્સ પર આ સમસ્યાઓનો સામનો કરવો પડ્યો, જેના પરિણામે અમે અમારી પ્લેબુકમાં ચલોને ફોર્મેટિંગ કરવાના નિયમો પર આવ્યા, જેણે અમુક અંશે આ સમસ્યાઓ હલ કરી.

ભૂમિકાઓમાં ચલ

ભૂમિકા એ એક અલગ ડિપ્લોયમેન્ટ સિસ્ટમ ઑબ્જેક્ટ છે. સિસ્ટમના કોઈપણ ઑબ્જેક્ટની જેમ, તેની પાસે બાકીની સિસ્ટમ સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે ઇન્ટરફેસ હોવું આવશ્યક છે. રોલ વેરીએબલ્સ આવા ઇન્ટરફેસ છે.

ઉદાહરણ તરીકે, ભૂમિકા લો api, જે સર્વર પર Java એપ્લિકેશન ઇન્સ્ટોલ કરે છે. તેમાં કયા ચલો છે?

રોલ વેરીએબલ્સને પ્રકાર દ્વારા 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

જમાવટ પ્લેબુકમાં ચલ

ડિપ્લોયમેન્ટ પ્લેબુકનું કમ્પાઈલ કરતી વખતે (ત્યારબાદ તેને પ્લેબુક તરીકે ઓળખવામાં આવે છે), અમે નિયમનું પાલન કરીએ છીએ કે તેને અલગ રીપોઝીટરીમાં મૂકવી જોઈએ. ભૂમિકાઓની જેમ જ: દરેક તેના પોતાના ગિટ રિપોઝીટરીમાં. આ તમને એ સમજવાની મંજૂરી આપે છે કે ભૂમિકાઓ અને પ્લેબુક ડિપ્લોયમેન્ટ સિસ્ટમના અલગ-અલગ સ્વતંત્ર ઑબ્જેક્ટ છે, અને એક ઑબ્જેક્ટમાં ફેરફાર અન્ય ઑપરેશનને અસર કરતું નથી. આ ચલોની મૂળભૂત કિંમતો બદલીને પ્રાપ્ત થાય છે.

પ્લેબુકનું સંકલન કરતી વખતે, સારાંશ માટે, રોલ વેરીએબલ્સના ડિફૉલ્ટ મૂલ્યોને બે જગ્યાએ ઓવરરાઇડ કરવું શક્ય છે: પ્લેબુક ચલો અને ઇન્વેન્ટરી ચલોમાં.

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 માં અલગ Java એપ્લિકેશન સાથે, પરંતુ વિવિધ સેટિંગ્સ સાથે સર્વરના 2 જૂથો ઉમેરીને અમારા મોડેલને વિસ્તૃત કરીએ.

કલ્પના કરો કે આ કિસ્સામાં પ્લેબુક કેવી દેખાશે:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

પ્લેબુકમાં અમારી પાસે ત્રણ જૂથો છે, તેથી જૂથ_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