ansible devops codestyle
ဟေး! ကျွန်တော့်အမည်မှာ ကျွန်ုပ်သည် ဖွံဖြိုးရေးလုပ်ငန်းစဉ် အလိုအလျောက်စနစ်ဌာနတွင် အင်ဂျင်နီယာတစ်ဦးအဖြစ် အလုပ်လုပ်ပါသည်။ နေ့တိုင်း၊ ရာနှင့်ချီသော ကမ်ပိန်းဆာဗာများတွင် အပလီကေးရှင်းအသစ်များ တည်ဆောက်သည်။ ဤဆောင်းပါးတွင် ဤရည်ရွယ်ချက်များအတွက် Ansible ကိုအသုံးပြုခြင်းအတွေ့အကြုံကို ကျွန်ုပ်မျှဝေပါသည်။
ဤလမ်းညွှန်ချက်သည် ဖြန့်ကျက်မှုတွင် ကိန်းရှင်များကို စုစည်းရန် နည်းလမ်းတစ်ခု ပေးထားသည်။ ဤလမ်းညွှန်သည် ၎င်းတို့၏ ကစားစာအုပ်များတွင် အခန်းကဏ္ဍများကို အသုံးပြုပြီး ဖတ်ဖူးသူများအတွက် ရည်ရွယ်ပါသည်။ သို့သော် အလားတူပြဿနာများ ရင်ဆိုင်နေရသည်-
- ကုဒ်တွင် ကိန်းရှင်တစ်ခုကို တွေ့ရှိပါက၊ ၎င်းတွင် တာဝန်ရှိသည်ကို ချက်ချင်းနားလည်ရန် မဖြစ်နိုင်ပေ။
- အခန်းကဏ္ဍများစွာရှိပြီး၊ ကိန်းရှင်များသည် တန်ဖိုးတစ်ခုနှင့် ဆက်စပ်မှုရှိရန် လိုအပ်သော်လည်း ၎င်းသည် အလုပ်မဖြစ်ပါ။
- သင့် playbooks များရှိ variables များ၏ logic အလုပ်လုပ်ပုံကို အခြားသူများအား ရှင်းပြရန် အခက်အခဲရှိခြင်း။
ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ ကုမ္ပဏီရှိ ပရောဂျက်များတွင် ဤပြဿနာများကို ကြုံတွေ့ခဲ့ရပြီး ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ playbooks များတွင် ကိန်းရှင်များကို ဒီဇိုင်းရေးဆွဲခြင်းအတွက် စည်းမျဉ်းများအတိုင်း ချမှတ်ထားသောကြောင့် ဤပြဿနာများကို အတိုင်းအတာတစ်ခုအထိ ဖြေရှင်းနိုင်ခဲ့ပါသည်။
အခန်းကဏ္ဍများတွင် ပြောင်းလွဲမှုများ
အခန်းကဏ္ဍတစ်ခုသည် ဖြန့်ကျက်မှုစနစ်၏ သီးခြားအရာဝတ္ထုတစ်ခုဖြစ်သည်။ မည်သည့်စနစ်အရာဝတ္တုကဲ့သို့ပင်၊ ၎င်းတွင် ကျန်ရှိသောစနစ်နှင့် အပြန်အလှန်ဆက်သွယ်ရန်အတွက် အင်တာဖေ့စ်တစ်ခုရှိရမည်။ ထိုသို့သော အင်တာဖေ့စ်သည် အခန်းကဏ္ဍ ကိန်းရှင်များဖြစ်သည်။
ဥပမာ၊ အခန်းကဏ္ဍကို ကြည့်ကြပါစို့ apiဆာဗာပေါ်တွင် Java အပလီကေးရှင်းကို ထည့်သွင်းပေးသော၊ ၎င်းတွင် မည်သည့်ပြောင်းလဲမှုများ ရှိနိုင်သနည်း။
အမျိုးအစားအလိုက် ပြောင်းလဲနိုင်သော အခန်းကဏ္ဍများကို အမျိုးအစား ၂ မျိုး ခွဲခြားနိုင်သည်။
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
ပြောင်းလဲနိုင်သော ဂုဏ်သတ္တိများ အခန်းကဏ္ဍတစ်ခု၏ အပြုအမူကို ဆုံးဖြတ်သည့် ကိန်းရှင်များဖြစ်သည်။
Query Variables - ၎င်းတို့သည် အခန်းကဏ္ဍပြင်ပမှ အရင်းအမြစ်များကို သတ်မှတ်ရန် တန်ဖိုးကို အသုံးပြုထားသော ကိန်းရှင်များဖြစ်သည်။
ပြောင်းလဲနိုင်သော နားထောင်သူများ - ဤအရာများသည် တောင်းဆိုမှုကိန်းရှင်များဖွဲ့စည်းရန် တန်ဖိုးကိုအသုံးပြုသည့် ကိန်းရှင်များဖြစ်သည်။
အခြားတစ်ဖက်တွင်၊ 1a၊ 2a၊ 2b များသည် ပတ်ဝန်းကျင် (ဟာ့ဒ်ဝဲ၊ ပြင်ပအရင်းအမြစ်များ စသည်ဖြင့်) ပေါ်တွင်မူတည်ခြင်းမရှိသော ကိန်းရှင်များဖြစ်ပြီး defaults အခန်းကဏ္ဍတွင် ပုံသေတန်ဖိုးများနှင့် ပြည့်နေနိုင်သည်။ သို့သော်၊ အမျိုးအစား 1.b နှင့် 2.c ၏ variable များကို 'example' မှလွဲ၍ အခြားတန်ဖိုးများဖြင့် ဖြည့်စွက်ရန် မဖြစ်နိုင်သောကြောင့်၊ ၎င်းတို့သည် ပတ်ဝန်းကျင်အပေါ် မူတည်၍ stand မှ stand သို့ ပြောင်းလဲသွားမည်ဖြစ်သည်။
ကုဒ်စတိုင်
- ပြောင်းလဲနိုင်သောအမည်သည် အခန်းကဏ္ဍအမည်ဖြင့် စတင်ရပါမည်။ ၎င်းသည် အနာဂတ်တွင် variable ၏ အခန်းကဏ္ဍမှ မည်သည့်အခန်းကဏ္ဍနှင့် ၎င်းအတွက်တာဝန်ရှိသည်တို့ကို အလွယ်တကူ သိရှိနိုင်မည်ဖြစ်သည်။
- အခန်းကဏ္ဍများတွင် variable များကိုအသုံးပြုသည့်အခါ၊ သင်သည် encapsulation ၏နိယာမကိုသေချာလိုက်နာပြီး အခန်းကဏ္ဍကိုယ်တိုင် သို့မဟုတ် လက်ရှိမူတည်သည့်အခန်းကဏ္ဍများတွင်သတ်မှတ်ထားသော variable များကိုအသုံးပြုရန်သေချာရပါမည်။
-
ကိန်းရှင်များအတွက် အဘိဓာန်များအသုံးပြုခြင်းကို ရှောင်ကြဉ်ပါ။ Ansible သည် အဘိဓာန်တစ်ခုတွင် တစ်ဦးချင်းတန်ဖိုးများကို အဆင်ပြေစွာ ကျော်လွှားရန် ခွင့်မပြုပါ။
မကောင်းတဲ့ ကိန်းရှင် ဥပမာ-
myrole_user: login: admin password: adminဤနေရာတွင် လော့ဂ်အင်သည် လွတ်လပ်သော ကိန်းရှင်ဖြစ်ပြီး၊ စကားဝှက်သည် မှီခိုသည့် ကိန်းရှင်ဖြစ်သည်။ ဒါပေမယ့်
၎င်းတို့ကို အဘိဓာန်တစ်ခုအဖြစ် ပေါင်းစပ်ထားသောကြောင့် ၎င်းကို လုံးလုံးသတ်မှတ်ရမည်ဖြစ်သည်။
အမြဲတမ်း။ အဲဒါက သိပ်အဆင်မပြေဘူး။ ဤနည်းဖြင့် ပိုကောင်းသည်-myrole_user_login: admin myrole_user_password: admin
အသုံးချပလေးစာအုပ်များတွင် ကွဲပြားမှုများ
ဖြန့်ကျက်ခြင်းဆိုင်ရာ ပလေးစာအုပ်ကို ပြုစုသောအခါ (နောင်တွင် ပလေးစာအုပ်ဟု ရည်ညွှန်းသည်)၊ ၎င်းအား သီးခြားသိုလှောင်မှုတွင် ထားရှိသင့်သည်ဟူသော စည်းမျဉ်းကို လိုက်နာပါသည်။ အခန်းကဏ္ဍများနှင့် တူညီသည်- တစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင် git repository တွင်ရှိသည်။ အခန်းကဏ္ဍများနှင့် ပလေးစာအုပ်များသည် ဖြန့်ကျက်မှုစနစ်၏ မတူညီသော သီးခြားအရာဝတ္ထုများဖြစ်ကြောင်း နားလည်နိုင်စေပြီး အရာဝတ္ထုတစ်ခုရှိ ပြောင်းလဲမှုများသည် အခြားတစ်ခု၏လုပ်ဆောင်မှုကို မထိခိုက်စေသင့်ပါ။ ကိန်းရှင်များ၏ ပုံသေတန်ဖိုးများကို ပြောင်းလဲခြင်းဖြင့် အောင်မြင်သည်။
အနှစ်ချုပ်ရရန်၊ playbook တစ်ခုကို ပြုစုသောအခါ၊ playbook variables များနှင့် inventory variables များတွင် နေရာနှစ်နေရာရှိ အခန်းကဏ္ဍ variable များ၏ မူရင်းတန်ဖိုးများကို override လုပ်နိုင်သည်။
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
ကွာခြားချက်မှာ playbook variable များသည် ၎င်းနှင့် တူညီသော အဆင့်တွင်ရှိသော playbooks များကို ခေါ်သောအခါတွင် အမြဲအသုံးပြုနေပါသည်။ ဆိုလိုသည်မှာ ဤကိန်းရှင်များသည် ပတ်ဝန်းကျင်-အမှီအခိုကင်းသော ကိန်းရှင်များ၏ ပုံသေတန်ဖိုးများကို ပြောင်းလဲရန်အတွက် ကောင်းမွန်ပါသည်။ အပြန်အလှန်အားဖြင့်၊ သိုလှောင်မှုကိန်းရှင်များကို သီးသန့်ပတ်ဝန်းကျင်တစ်ခုအတွက်သာ အသုံးပြုမည်ဖြစ်ပြီး၊ ၎င်းသည် ပတ်ဝန်းကျင်ဆိုင်ရာ သီးခြားကိန်းရှင်များအတွက် အကောင်းဆုံးဖြစ်သည်။
variable ဦးစားပေးသည် သင့်အား playbook variables များတွင် ပထမဦးစွာ variable များကို override လုပ်ခွင့်မပြုဘဲ inventory တစ်ခုတွင် သီးခြားခွဲ၍မရကြောင်း သတိပြုရန် အရေးကြီးပါသည်။
ဆိုလိုသည်မှာ ဤအဆင့်တွင် ကိန်းရှင်သည် ပတ်၀န်းကျင်ကို မှီခိုခြင်းရှိ၊ မရှိ ဆုံးဖြတ်ပြီး သင့်လျော်သောနေရာတွင် ထားရှိရန် လိုအပ်သည်ဟု ဆိုလိုသည်။
ဥပမာအားဖြင့်၊ ပရောဂျက်တစ်ခုတွင်၊ SSL ကိုဖွင့်ရန်တာဝန်ရှိ variable သည် အချိန်အတော်ကြာအောင် သဘာဝပတ်ဝန်းကျင်အပေါ် မှီခိုနေသောကြောင့် SSL ကို ကျွန်ုပ်တို့၏ထိန်းချုပ်မှုထက်ကျော်လွန်သည့်အကြောင်းပြချက်များအတွက် SSL ကိုဖွင့်၍မရပါ။ ဤပြဿနာကို ကျွန်ုပ်တို့ဖြေရှင်းပြီးနောက်၊ ၎င်းသည် ပတ်ဝန်းကျင်တွင် အမှီအခိုကင်းလာပြီး playbook variable များဆီသို့ ပြောင်းရွှေ့သွားခဲ့သည်။
အုပ်စုများအတွက် ပိုင်ဆိုင်မှု Variables
မတူညီသော Java အပလီကေးရှင်းတစ်ခုဖြင့် ဆာဗာအုပ်စု ၂ ခုကို ပေါင်းထည့်ခြင်းဖြင့် ပုံ ၁ တွင် ကျွန်ုပ်တို့၏မော်ဒယ်ကို ချဲ့ကြည့်ကြပါစို့။
ဤကိစ္စတွင် Playbook သည်မည်သို့မည်ပုံရှိမည်ကိုစိတ်ကူးကြည့်ကြပါစို့။
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authကျွန်ုပ်တို့တွင် ပလေးစာအုပ်တွင် အုပ်စုသုံးစုရှိသည်၊ ထို့ကြောင့် group_vars စာရင်းဇယားကိန်းရှင်များနှင့် ပလေးစာအုပ်ကွဲလွဲချက်များတွင် အုပ်စုဖိုင်အရေအတွက်တူညီစွာဖန်တီးရန် အကြံပြုထားသည်။ ဤကိစ္စတွင် အုပ်စုဖိုင်တစ်ခုသည် playbook ရှိ အထက်ပါ အပလီကေးရှင်း၏ အစိတ်အပိုင်းတစ်ခု၏ ဖော်ပြချက်ဖြစ်သည်။ playbook variables များတွင် အုပ်စုဖိုင်ကိုဖွင့်သောအခါ၊ အဖွဲ့တွင်ထည့်သွင်းထားသည့် အခန်းကဏ္ဍများ၏ ပုံသေအမူအကျင့်များမှ ကွဲပြားမှုများကို ချက်ချင်းတွေ့မြင်နိုင်သည်။ စာရင်းဇယားကိန်းရှင်များတွင်- အုပ်စုအမူအကျင့်ဆိုင်ရာ ကွဲပြားမှုများ။
ကုဒ်ပုံစံ
- ၎င်းတို့သည် စနစ်အား မဖော်ပြထားသောကြောင့်၊ host_vars variables များကို လုံးဝအသုံးမပြုပါနှင့်၊ ၎င်းတို့သည် အနာဂတ်တွင် မေးခွန်းများဖြစ်လာစေမည့် အထူးကိစ္စရပ်တစ်ခုသာဖြစ်သောကြောင့် "ဤ host သည် အခြားသူများနှင့် ဘာကြောင့်ကွာခြားသနည်း"၊ အဖြေမဟုတ်ပေ။ ရှာရန်အမြဲလွယ်ကူသည်။
ဆက်သွယ်ရေး ပြောင်းလဲမှုများ
သို့သော်၊ ဤအရာသည် ပိုင်ဆိုင်မှု ကိန်းရှင်များ အကြောင်းဖြစ်သည်၊ သို့သော် ဆက်သွယ်မှု ကိန်းရှင်များကော။
သူတို့၏ ခြားနားချက်မှာ မတူညီသော အုပ်စုများတွင် တူညီသော အဓိပ္ပါယ်ရှိသင့်သည်။
ပထမတော့ အဲဒါပါပဲ။ ကြီးကျယ်ခမ်းနားသော ဆောက်လုပ်ရေးကို အသုံးပြုပါ
hostvars[groups['bbauth'][0]]['auth_bind_port']ဒါပေမယ့် သူတို့က ချက်ချင်း ငြင်းတယ်။
ဘာလို့လဲဆိုတော့ သူ့မှာ အားနည်းချက်တွေရှိတယ်။ ပထမအချက်၊ ကြီးမားသည်။ ဒုတိယအနေဖြင့်၊ အုပ်စုအတွင်းရှိ သီးခြားအိမ်ရှင်တစ်ဦးအပေါ် မှီခိုမှု။ တတိယအနေဖြင့်၊ သတ်မှတ်မထားသော variable ၏အမှားအယွင်းတစ်ခုမလိုချင်ပါက၊ deployment မစတင်မီ၊ host အားလုံးထံမှ အချက်အလက်များကို စုဆောင်းရန်လိုအပ်ပါသည်။
ရလဒ်အနေဖြင့် ဆက်သွယ်မှုပြောင်းလွဲချက်များကို အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။
ဆက်သွယ်ရေး ပြောင်းလဲမှုများ - ဤအရာများသည် playbook နှင့်သက်ဆိုင်ပြီး စနစ်အရာဝတ္ထုများကို ချိတ်ဆက်ရန်အတွက် လိုအပ်သော ကိန်းရှင်များဖြစ်သည်။
ဆက်သွယ်ရေး ကိန်းရှင်များကို ယေဘူယျစနစ် ကိန်းရှင်များတွင် ထည့်သွင်းထားသည်။ group_vars/all/vars အုပ်စုတစ်ခုစီမှ နားဆင်သူ variable အားလုံးကို ဖယ်ရှားပြီး နားဆင်သူမှ ဖယ်ရှားခဲ့သည့် ကိန်းရှင်၏အစတွင် အုပ်စု၏အမည်ကို ပေါင်းထည့်ခြင်းဖြင့် ဖွဲ့စည်းထားပါသည်။
၎င်းသည် အမည်များ၏ တူညီမှုနှင့် ထပ်နေခြင်းမရှိကြောင်း သေချာစေသည်။
အပေါ်က ဥပမာကနေ variable တွေကို ချိတ်ဖို့ ကြိုးစားကြည့်ရအောင်။
ကျွန်ုပ်တို့တွင် တစ်ခုနှင့်တစ်ခုအပေါ် မူတည်သော ကိန်းရှင်များရှိသည်ဟု စိတ်ကူးကြည့်ကြပါစို့။
# 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 လက်မှတ်များဖြစ်သည်။ ၎င်းတို့ကို စာသားပုံစံဖြင့် သိမ်းဆည်းပါ။
variable မှာ သိပ်အဆင်ပြေမှာမဟုတ်ပါဘူး။ ဒါပေမယ့် သူတို့ဆီသွားတဲ့လမ်းကြောင်းကို variable တစ်ခုထဲမှာ သိမ်းထားရတာ အဆင်ပြေတယ်။
ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် variable ကိုအသုံးပြုသည်။ api_ssl_key_file: "/path/to/file".
သော့လက်မှတ်သည် ပတ်ဝန်းကျင်မှ ပတ်၀န်းကျင်သို့ ပြောင်းလဲသွားကြောင်း သိသာထင်ရှားသောကြောင့်၊ ၎င်းသည် ဖိုင်ထဲတွင် ရှိနေသင့်သည်ဟု ဆိုလိုသည်မှာ ပတ်ဝန်းကျင်-မှီခိုပြောင်းလဲမှုတစ်ခုဖြစ်သည်။
group_vars/myapi/vars ကိန်းရှင်များစာရင်းတွင် 'ဥပမာ' တန်ဖိုးပါရှိသည်။
ဤကိစ္စတွင် အဆင်ပြေဆုံးနည်းလမ်းမှာ playbook repository တွင် သော့ဖိုင်ကို လမ်းကြောင်းတစ်လျှောက် ထားခြင်းဖြစ်သည်။
files/prod/certs/myapi.keyထို့နောက် variable ၏တန်ဖိုးသည်-
api_ssl_key_file: "prod/certs/myapi.key". အဆင်ပြေမှုမှာ သီးခြားရပ်တည်ချက်တစ်ခုတွင် စနစ်ကို ဖြန့်ကျက်လုပ်ဆောင်ရန် တာဝန်ရှိသူများသည် ၎င်းတို့၏ဖိုင်များကို သိမ်းဆည်းရန် repository တွင် ကိုယ်ပိုင်သီးသန့်နေရာ ရှိသည်ဟူသောအချက်၌ တည်ရှိနေပါသည်။ တစ်ချိန်တည်းမှာပင်၊ လက်မှတ်များကို အခြားစနစ်က ပံ့ပိုးပေးသောအခါတွင်၊ ဆာဗာပေါ်ရှိ လက်မှတ်များဆီသို့ အကြွင်းမဲ့လမ်းကြောင်းကို သတ်မှတ်ရန် ဖြစ်နိုင်ချေရှိသေးသည်။
ပတ်ဝန်းကျင်တစ်ခုတွင် ရပ်တည်မှုအများအပြား
မကြာခဏဆိုသလို မတူညီမှုအနည်းငယ်မျှသာရှိသော တူညီသောပတ်ဝန်းကျင်တွင် တူညီလုနီးပါးတူညီသောရပ်တည်ချက်များကို အသုံးချရန် လိုအပ်ပါသည်။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် ဤပတ်ဝန်းကျင်အတွင်း မပြောင်းလဲသော ပြောင်းလဲမှုများနှင့် ပြောင်းလဲသော အရာများအဖြစ် ပတ်ဝန်းကျင်ကို မှီခိုသော ကိန်းရှင်များကို ပိုင်းခြားထားပါသည်။ ထို့နောက် ၎င်းတို့ကို စာရင်းဖိုင်များထဲသို့ တိုက်ရိုက်လွှဲပြောင်းပေးပါသည်။ ဤခြယ်လှယ်မှုပြီးနောက်၊ ပတ်ဝန်းကျင်လမ်းညွှန်တွင် အခြားစာရင်းအင်းများကို ဖန်တီးနိုင်သည်။
၎င်းသည် 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အနှစ်ချုပ်
ဆောင်းပါးနှင့်အညီ variable များကို စုစည်းပြီးနောက်- variable file တစ်ခုစီသည် သီးခြားလုပ်ငန်းတစ်ခုအတွက် တာဝန်ရှိသည်။ ဖိုင်တွင် အချို့သော လုပ်ဆောင်စရာများ ရှိသောကြောင့်၊ ဖိုင်တစ်ခုစီ၏ မှန်ကန်မှုအတွက် တာဝန်ရှိသူတစ်ဦးကို တာဝန်ပေးအပ်ရန် ဖြစ်နိုင်သည်။ ဥပမာအားဖြင့်၊ စနစ်ဖြန့်ကျက်မှု၏ developer သည် playbook variable များကိုမှန်ကန်သောဖြည့်စွက်မှုအတွက်တာဝန်ရှိပြီးစာရင်းတွင်ဖော်ပြထားသောရပ်တည်ချက်၏စီမံခန့်ခွဲသူသည် variable များစာရင်းကိုဖြည့်ရန်တိုက်ရိုက်တာဝန်ရှိသည်။
Roles သည် ၎င်းတို့၏ကိုယ်ပိုင်အင်တာဖေ့စ်နှင့် သီးခြားဖွံ့ဖြိုးတိုးတက်မှုယူနစ်ဖြစ်လာပြီး အခန်းကဏ္ဍပြုစုသူအား စနစ်၏အခန်းကဏ္ဍကို အံဝင်ခွင်ကျဖြစ်စေမည့်အစား စွမ်းဆောင်ရည်များ ဖွံ့ဖြိုးတိုးတက်လာစေရန် ခွင့်ပြုပေးခဲ့သည်။ အထူးသဖြင့် ဤပြဿနာသည် မဲဆွယ်စည်းရုံးရေးရှိ စနစ်အားလုံးအတွက် ဘုံအခန်းကဏ္ဍများနှင့် သက်ဆိုင်ပါသည်။
စနစ်စီမံခန့်ခွဲသူများသည် ဖြန့်ကျက်ကုဒ်ကို နားလည်ရန်မလိုအပ်တော့ပါ။ အောင်မြင်စွာ ဖြန့်ကျက်ရန်အတွက် ၎င်းတို့ထဲမှ လိုအပ်သည့်အရာအားလုံးမှာ ပတ်၀န်းကျင်ကို မှီခိုနေသည့် variable များ၏ ဖိုင်များကို ဖြည့်ရန်ဖြစ်သည်။
စာပေ
စာရေးသူ
Kalyuzhny Denis Alexandrovich
source: www.habr.com