በተለዋዋጮች ውስጥ የስርዓት አቀራረብ

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   # Секреты (всегда средозависимы) *

* - ተለዋዋጮች እና ቮልት

ልዩነቱ የመጫወቻ መጽሐፍ ተለዋዋጮች ሁል ጊዜ ጥቅም ላይ የሚውሉት የመጫወቻ መጽሐፍት በሚጠሩበት ጊዜ በተመሳሳይ ደረጃ ላይ የሚገኙ መሆናቸው ነው። ይህ ማለት እነዚህ ተለዋዋጮች የአካባቢ-ተኮር ተለዋዋጮች ነባሪ እሴቶችን ለመለወጥ ጥሩ ናቸው። በተቃራኒው፣ የእቃ ዝርዝር ተለዋዋጮች ለአንድ የተወሰነ አካባቢ ብቻ ጥቅም ላይ ይውላሉ፣ ይህም ለአካባቢ-ተኮር ተለዋዋጮች ተስማሚ ነው።

የተለዋዋጭ ቀዳሚነት ተለዋዋጮችን በመጀመሪያ በመጫወቻ ደብተር ተለዋዋጮች እና ከዚያም በተናጠል በአንድ ኢንቬንቶ ውስጥ ለመሻር እንደማይፈቅድ ልብ ማለት ያስፈልጋል።

ይህ ማለት ቀድሞውኑ በዚህ ደረጃ ላይ ተለዋዋጭው በአካባቢ ላይ የተመሰረተ መሆኑን ወይም አለመሆኑን መወሰን እና በተገቢው ቦታ ላይ ማስቀመጥ ያስፈልጋል.

ለምሳሌ፣ በአንድ ፕሮጀክት ውስጥ፣ ኤስኤስኤልን ከአቅማችን በላይ በሆነ ምክንያት ኤስኤስኤልን ማንቃት ስላልቻልን ኤስኤስኤልን ለማንቃት ሃላፊነት ያለው ተለዋዋጭ ለረጅም ጊዜ በአካባቢ ላይ የተመሰረተ ነበር። ይህንን ችግር ካስተካከልን በኋላ፣ አካባቢ ራሱን የቻለ እና ወደ playbook ተለዋዋጮች ተዛወረ።

ለቡድኖች የንብረት ተለዋዋጮች

በተለየ የጃቫ አፕሊኬሽን 1 ቡድኖችን በማከል ሞዴላችንን በስእል 2 እናስፋፋ።

በዚህ ጉዳይ ላይ የመጫወቻ ደብተሩ ምን እንደሚመስል እናስብ፡-

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

በመጫወቻ ደብተር ውስጥ ሶስት ቡድኖች አሉን ፣ ስለሆነም ወዲያውኑ የቡድን_ቫርስ ኢንቬንቶሪ ተለዋዋጮች እና የመጫወቻ መጽሐፍ ተለዋዋጮች ውስጥ ተመሳሳይ የቡድን ፋይሎችን ለመፍጠር ይመከራል። በዚህ ጉዳይ ላይ አንድ የቡድን ፋይል በመጫወቻ ደብተር ውስጥ ከላይ ያለው መተግበሪያ አንድ አካል መግለጫ ነው. በመጫወቻ መጽሐፍ ተለዋዋጮች ውስጥ የቡድን ፋይል ሲከፍቱ ወዲያውኑ በቡድኑ ላይ ከተጫኑት ሚናዎች ነባሪ ባህሪ ሁሉንም ልዩነቶች ያያሉ። በኢንቬንቶሪ ተለዋዋጮች፡ የቡድን ባህሪ ከቆመበት እስከ መቆም ልዩነት።

ኮድ ዘይቤ

• የ 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". ምቾቱ ስርዓቱን በአንድ የተወሰነ ቦታ ላይ የማሰማራት ኃላፊነት ያለባቸው ሰዎች እንዲሁ በማጠራቀሚያው ውስጥ ፋይሎቻቸውን ለማከማቸት የራሳቸው የሆነ ቦታ ስላላቸው ነው። በተመሳሳይ ጊዜ የምስክር ወረቀቶች በሌላ ስርዓት የሚቀርቡ ከሆነ በአገልጋዩ ላይ የምስክር ወረቀቱን ፍጹም መንገድ መግለጽ ይቻላል ።

በአንድ አካባቢ ውስጥ በርካታ ማቆሚያዎች

ብዙ ጊዜ ከሞላ ጎደል ተመሳሳይ የሆኑ መቆሚያዎችን በትንሽ ልዩነት በአንድ አካባቢ ማሰማራት ያስፈልጋል። በዚህ ሁኔታ, በአካባቢ ላይ ጥገኛ የሆኑ ተለዋዋጮችን በዚህ አካባቢ ውስጥ የማይለወጡ እና የሚለወጡ ወደሚሆኑ እንከፋፍላለን. እና የኋለኛውን በቀጥታ ወደ የእቃዎቹ ፋይሎች እራሳቸው እናስተላልፋለን. ከዚህ ማጭበርበር በኋላ, በአካባቢ ዳይሬክተሩ ውስጥ ሌላ ኢንቬንቶሪ መፍጠር ይቻላል.

የቡድን_ቫርስ ክምችትን እንደገና ይጠቀማል፣ እና አንዳንድ ተለዋዋጮችን በቀጥታ ለራሱ መወሰን ይችላል።

የማሰማራቱ ፕሮጀክት የመጨረሻው የማውጫ መዋቅር፡-

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. ሰነድ

ደራሲ

ካሊዩዝኒ ዴኒስ አሌክሳንድሮቪች

ምንጭ: hab.com