🥇એન્સિબલ ટેસ્ટિંગ કેવી રીતે શરૂ કરવું, એક વર્ષમાં પ્રોજેક્ટ રિફેક્ટ કરો અને પાગલ ન થાઓ

આ ટ્રાન્સક્રિપ્ટ છે પ્રદર્શન પર DevOps-40 2020-03-18:

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

વારસાનો જન્મ

દિવસ #1: દર્દી શૂન્ય

એક સમયે એક શરતી પ્રોજેક્ટ હતો. તેમાં દેવ વિકાસ ટીમ અને ઓપ્સ એન્જિનિયરો હતા. તેઓ એ જ સમસ્યા હલ કરી રહ્યા હતા: સર્વર કેવી રીતે જમાવવું અને એપ્લિકેશન કેવી રીતે ચલાવવી. સમસ્યા એ હતી કે દરેક ટીમે આ સમસ્યાને પોતાની રીતે હલ કરી. પ્રોજેક્ટમાં, દેવ અને ઓપ્સ ટીમો વચ્ચે જ્ઞાનને સુમેળ કરવા માટે Ansible નો ઉપયોગ કરવાનું નક્કી કરવામાં આવ્યું હતું.

દિવસ #89: વારસાનો જન્મ

પોતાને ધ્યાનમાં લીધા વિના, તેઓ તેને શક્ય તેટલું શ્રેષ્ઠ કરવા માંગતા હતા, પરંતુ તે વારસો હોવાનું બહાર આવ્યું. આ કેવી રીતે થાય છે?

અમારે અહીં એક તાકીદનું કાર્ય છે, ચાલો એક ગંદા હેક કરીએ અને પછી તેને ઠીક કરીએ.
તમારે દસ્તાવેજો લખવાની જરૂર નથી અને અહીં શું થઈ રહ્યું છે તે બધું સ્પષ્ટ છે.
હું જવાબી/પાયથોન/બેશ/ટેરાફોર્મ જાણું છું! જુઓ કે હું કેવી રીતે ડોજ કરી શકું છું!
હું સંપૂર્ણ સ્ટેક ઓવરફ્લો ડેવલપર છું અને સ્ટેકઓવરફ્લોમાંથી આની નકલ કરી છે, મને ખબર નથી કે તે કેવી રીતે કાર્ય કરે છે, પરંતુ તે સરસ લાગે છે અને સમસ્યાનું નિરાકરણ લાવે છે.

પરિણામે, તમે એક અગમ્ય પ્રકારનો કોડ મેળવી શકો છો જેના માટે કોઈ દસ્તાવેજો નથી, તે શું કરે છે, તેની જરૂર છે કે કેમ તે સ્પષ્ટ નથી, પરંતુ સમસ્યા એ છે કે તમારે તેને વિકસાવવાની, તેને સંશોધિત કરવાની, ક્રેચ અને સપોર્ટ ઉમેરવાની જરૂર છે. , પરિસ્થિતિ વધુ ખરાબ બનાવે છે.

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

દિવસ #109: સમસ્યાની જાગૃતિ

શરૂઆતમાં કલ્પના કરાયેલ અને અમલમાં મૂકાયેલ IaC મોડલ હવે વપરાશકર્તાઓ/વ્યવસાય/અન્ય ટીમોની જરૂરિયાતોને પૂર્ણ કરતું નથી, અને ઇન્ફ્રાસ્ટ્રક્ચરમાં ફેરફાર કરવાનો સમય સ્વીકાર્ય નથી. આ ક્ષણે, સમજણ આવે છે કે તે પગલાં લેવાનો સમય છે.

IaC રિફેક્ટરિંગ

દિવસ #139: શું તમને ખરેખર રિફેક્ટરિંગની જરૂર છે?

તમે રિફેક્ટરમાં દોડી જાઓ તે પહેલાં, તમારે સંખ્યાબંધ મહત્વપૂર્ણ પ્રશ્નોના જવાબ આપવા આવશ્યક છે:

તમારે આ બધાની શા માટે જરૂર છે?
શું તમારી પાસે સમય છે?
શું જ્ઞાન પૂરતું છે?

જો તમે પ્રશ્નોના જવાબ કેવી રીતે આપવા તે જાણતા નથી, તો રિફેક્ટિંગ શરૂ થાય તે પહેલાં જ સમાપ્ત થઈ જશે, અથવા તે વધુ ખરાબ થઈ શકે છે. કારણ કે અનુભવ હતો ( ઇન્ફ્રાસ્ટ્રક્ચર કોડની 200 લાઇનના પરીક્ષણમાંથી હું શું શીખ્યો), પછી પ્રોજેક્ટને ભૂમિકાઓને ઠીક કરવા અને પરીક્ષણો સાથે આવરી લેવા માટે મદદ માટે વિનંતી મળી.

દિવસ #149: રિફેક્ટરિંગની તૈયારી

પ્રથમ વસ્તુ તૈયાર કરવાની છે. અમે શું કરીશું તે નક્કી કરો. આ કરવા માટે, અમે વાતચીત કરીએ છીએ, સમસ્યાના વિસ્તારો શોધીએ છીએ અને તેમને હલ કરવાની રીતો શોધીએ છીએ. અમે પરિણામી વિભાવનાઓને કોઈક રીતે રેકોર્ડ કરીએ છીએ, ઉદાહરણ તરીકે સંગમમાં એક લેખ, જેથી જ્યારે પ્રશ્ન ઊભો થાય કે "શ્રેષ્ઠ શું છે?" અથવા "કયું સાચું છે?" અમે અમારો રસ્તો ગુમાવ્યો નથી. અમારા કિસ્સામાં, અમે વિચાર પર અટકી ગયા ભાગલા પાડો અને રાજ કરો: અમે ઇન્ફ્રાસ્ટ્રક્ચરને નાના ટુકડા/ઇંટોમાં વિભાજીત કરીએ છીએ. આ અભિગમ તમને ઇન્ફ્રાસ્ટ્રક્ચરનો એક અલગ ભાગ લેવા, તે શું કરે છે તે સમજવા, તેને પરીક્ષણો સાથે આવરી લેવા અને કંઈપણ તૂટવાના ડર વિના તેને બદલવાની મંજૂરી આપે છે.

તે તારણ આપે છે કે ઇન્ફ્રાસ્ટ્રક્ચર પરીક્ષણ પાયાનો પથ્થર બની જાય છે અને અહીં તે ઇન્ફ્રાસ્ટ્રક્ચર પરીક્ષણ પિરામિડનો ઉલ્લેખ કરવા યોગ્ય છે. બરાબર એ જ વિચાર જે વિકાસમાં છે, પરંતુ ઈન્ફ્રાસ્ટ્રક્ચર માટે: અમે સસ્તા ઝડપી પરીક્ષણોથી આગળ વધી રહ્યા છીએ જે સરળ વસ્તુઓની તપાસ કરે છે, જેમ કે ઇન્ડેન્ટેશન, ખર્ચાળ સંપૂર્ણ પરીક્ષણો તરફ આગળ વધી રહ્યા છીએ જે સમગ્ર ઈન્ફ્રાસ્ટ્રક્ચરનો ઉપયોગ કરે છે.

જવાબ આપવા યોગ્ય પરીક્ષણ પ્રયાસો

અમે પ્રોજેક્ટ પર જવાબી કસોટીઓને કેવી રીતે આવરી લીધી તેનું વર્ણન કરવા જઈએ તે પહેલાં, હું લીધેલા નિર્ણયોના સંદર્ભને સમજવા માટે મને અગાઉ ઉપયોગ કરવાની તક મળી હોય તેવા પ્રયાસો અને અભિગમોનું વર્ણન કરીશ.

દિવસ નંબર -997: SDS જોગવાઈ

પ્રથમ વખત મેં એન્સિબલનું પરીક્ષણ કર્યું તે SDS (સોફ્ટવેર ડિફાઈન્ડ સ્ટોરેજ) વિકસાવવાના પ્રોજેક્ટ પર હતું. આ વિષય પર એક અલગ લેખ છે
તમારા વિતરણનું પરીક્ષણ કરતી વખતે સાયકલને ક્રચ પર કેવી રીતે તોડવી, પરંતુ ટૂંકમાં, અમે એક ઊંધી પરીક્ષણ પિરામિડ સાથે સમાપ્ત કર્યું અને પરીક્ષણ અમે એક ભૂમિકા પર 60-90 મિનિટ ગાળ્યા, જે ઘણો લાંબો સમય છે. આધાર e2e પરીક્ષણો હતો, એટલે કે. અમે સંપૂર્ણ સુવિધાયુક્ત ઇન્સ્ટોલેશન જમાવ્યું અને પછી તેનું પરીક્ષણ કર્યું. તેનાથી પણ વધુ ઉત્તેજનાજનક બાબત એ હતી કે તેની પોતાની સાયકલની શોધ. પરંતુ મારે કબૂલ કરવું જોઈએ, આ ઉકેલે કામ કર્યું અને સ્થિર પ્રકાશન માટે મંજૂરી આપી.

દિવસ # -701: જવાબી અને પરીક્ષણ રસોડું

જવાબી પરીક્ષણ વિચારનો વિકાસ એ તૈયાર સાધનોનો ઉપયોગ હતો, જેમ કે ટેસ્ટ કિચન/કિચન-સીઆઈ અને ઈન્સ્પેક. પસંદગી રૂબીના જ્ઞાન દ્વારા નક્કી કરવામાં આવી હતી (વધુ વિગતો માટે, હેબ્રે પરનો લેખ જુઓ: શું YML પ્રોગ્રામરો જવાબી પરીક્ષણનું સ્વપ્ન ધરાવે છે?) ઝડપથી કામ કર્યું, લગભગ 40 મિનિટ 10 ભૂમિકાઓ માટે. અમે વર્ચ્યુઅલ મશીનોનું પેક બનાવ્યું અને અંદર પરીક્ષણો ચલાવ્યા.

સામાન્ય રીતે, સોલ્યુશન કામ કરતું હતું, પરંતુ વિજાતીયતાને કારણે થોડો કાંપ હતો. જ્યારે પરીક્ષણ કરાયેલા લોકોની સંખ્યા વધારીને 13 મૂળભૂત ભૂમિકાઓ અને 2 મેટા ભૂમિકાઓ સાથે નાની ભૂમિકાઓ સાથે જોડવામાં આવી, ત્યારે અચાનક પરીક્ષણો 70 મિનિટ સુધી ચાલવાનું શરૂ થયું, જે લગભગ 2 ગણું વધારે છે. XP (એક્સ્ટ્રીમ પ્રોગ્રામિંગ) પ્રેક્ટિસ વિશે વાત કરવી મુશ્કેલ હતી કારણ કે... કોઈ 70 મિનિટ રાહ જોવા માંગતું નથી. આ અભિગમ બદલવાનું કારણ હતું

દિવસ # -601: જવાબી અને પરમાણુ

વૈચારિક રીતે, આ ટેસ્ટકિચેન જેવું જ છે, માત્ર અમે રોલ ટેસ્ટિંગને ડોકરમાં ખસેડ્યું અને સ્ટેક બદલ્યો. પરિણામે, 20 ભૂમિકાઓ માટે સમય ઘટાડીને સ્થિર 25-7 મિનિટ કરવામાં આવ્યો.

ચકાસાયેલ ભૂમિકાઓની સંખ્યા વધારીને 17 અને 45 ભૂમિકાઓને લીંટીંગ કરીને, અમે 28 જેનકિન્સ સ્લેવ પર 2 મિનિટમાં આને ચલાવ્યું.

દિવસ #167: પ્રોજેક્ટમાં જવાબી પરીક્ષણો ઉમેરવાનું

મોટે ભાગે, ઉતાવળમાં રિફેક્ટરિંગ કાર્ય કરવું શક્ય બનશે નહીં. કાર્ય માપી શકાય તેવું હોવું જોઈએ જેથી કરીને તમે તેને નાના-નાના ટુકડા કરી શકો અને હાથીના ટુકડાને ચમચી વડે ખાઈ શકો. તમે સાચી દિશામાં આગળ વધી રહ્યા છો કે કેમ, ક્યાં સુધી આગળ વધવાનું છે તેની સમજ હોવી જોઈએ.

સામાન્ય રીતે, તે કેવી રીતે થશે તેનાથી કોઈ ફરક પડતો નથી, તમે કાગળના ટુકડા પર લખી શકો છો, તમે કબાટ પર સ્ટીકરો મૂકી શકો છો, તમે જીરામાં કાર્યો બનાવી શકો છો, અથવા તમે Google ડૉક્સ ખોલી શકો છો અને વર્તમાન સ્થિતિ લખી શકો છો. ત્યાં પગ એ હકીકતથી વધે છે કે પ્રક્રિયા તાત્કાલિક નથી, તે લાંબી અને કંટાળાજનક હશે. તે અસંભવિત છે કે કોઈ પણ ઇચ્છે છે કે તમે રિફેક્ટિંગ દરમિયાન વિચારોથી બળી જાઓ, થાકી જાઓ અને ભરાઈ જાઓ.

રિફેક્ટરિંગ સરળ છે:

ખાવું.
ઊંઘ
કોડ.
IaC ટેસ્ટ.
પુનરાવર્તન કરો

અને અમે ઇચ્છિત ધ્યેય સુધી પહોંચીએ ત્યાં સુધી અમે આનું પુનરાવર્તન કરીએ છીએ.

તરત જ દરેક વસ્તુનું પરીક્ષણ કરવાનું શરૂ કરવું શક્ય ન હોઈ શકે, તેથી અમારું પ્રથમ કાર્ય લિંટિંગ અને સિન્ટેક્સને તપાસવાનું હતું.

દિવસ #181: ગ્રીન બિલ્ડ માસ્ટર

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

લાલ પરીક્ષણો ખરાબ છે.
હું કંઈક ઠીક કરવા આવ્યો છું અને તે જ સમયે કોડને તે તમારા પહેલાં હતો તેના કરતા થોડો વધુ સારો બનાવો.

દિવસ #193: લિંટિંગથી લઈને યુનિટ ટેસ્ટ સુધી

માસ્ટરમાં કોડ મેળવવાની પ્રક્રિયાને બાંધ્યા પછી, તમે પગલું-દર-પગલાની સુધારણાની પ્રક્રિયા શરૂ કરી શકો છો - લૉન્ચિંગ ભૂમિકાઓ સાથે લિન્ટિંગને બદલીને, તમે આડેધડતા વિના પણ કરી શકો છો. તમારે ભૂમિકાઓ કેવી રીતે લાગુ કરવી અને તેઓ કેવી રીતે કાર્ય કરે છે તે સમજવાની જરૂર છે.

દિવસ #211: એકમથી એકીકરણ પરીક્ષણો

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

જેનકિન્સનો ઉપયોગ કરીને, અમે ઘણા તબક્કાઓ જનરેટ કર્યા છે જે સમાંતરમાં ભૂમિકાઓ/પ્લેબુકને લીંટ કરે છે, પછી કન્ટેનરમાં એકમ પરીક્ષણો અને અંતે એકીકરણ પરીક્ષણો.

જેનકિન્સ + ડોકર + જવાબી = ટેસ્ટ

રેપો ચેકઆઉટ કરો અને બિલ્ડ સ્ટેજ જનરેટ કરો.
લિન્ટ પ્લેબુક સ્ટેજને સમાંતર ચલાવો.
લિન્ટ રોલ સ્ટેજને સમાંતર ચલાવો.
સમાંતરમાં સિન્ટેક્સ ચેક રોલ સ્ટેજ ચલાવો.
ટેસ્ટ રોલ સ્ટેજ સમાંતર ચલાવો.
1. લિન્ટ ભૂમિકા.
2. અન્ય ભૂમિકાઓ પર નિર્ભરતા તપાસો.
3. વાક્યરચના તપાસો.
4. ડોકર દાખલો બનાવો
5. molecule/default/playbook.yml ચલાવો.
6. આડેધડતા તપાસો.
એકીકરણ પરીક્ષણો ચલાવો
સમાપ્ત

દિવસ #271: બસ ફેક્ટર

શરૂઆતમાં, રિફેક્ટરિંગ બે અથવા ત્રણ લોકોના નાના જૂથ દ્વારા હાથ ધરવામાં આવ્યું હતું. તેઓએ માસ્ટરમાં કોડની સમીક્ષા કરી. સમય જતાં, ટીમે કોડ કેવી રીતે લખવો તેનું જ્ઞાન વિકસાવ્યું અને કોડ રિવ્યુએ ઇન્ફ્રાસ્ટ્રક્ચર અને તે કેવી રીતે કાર્ય કરે છે તે વિશેના જ્ઞાનના પ્રસારમાં ફાળો આપ્યો. અહીંની વિશેષતા એ હતી કે સમીક્ષકોને એક પછી એક શેડ્યૂલ અનુસાર પસંદ કરવામાં આવ્યા હતા, એટલે કે. અમુક અંશે સંભાવના સાથે તમે ઇન્ફ્રાસ્ટ્રક્ચરના નવા ભાગમાં ચઢી જશો.

અને તે અહીં આરામદાયક હોવું જોઈએ. સમીક્ષા કરવી અનુકૂળ છે, તે શું કાર્ય કરવામાં આવ્યું હતું તેના માળખામાં અને ચર્ચાઓનો ઇતિહાસ જુઓ. અમે જેનકિન્સ + બીટબકેટ + જીરાને એકીકૃત કર્યું છે.

પરંતુ જેમ કે, સમીક્ષા એ રામબાણ ઉપાય નથી; કોઈક રીતે, અમે માસ્ટર કોડમાં પ્રવેશ્યા, જેણે અમને ફ્લોપ પરીક્ષણો બનાવ્યા:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

પછી તેઓએ તેને ઠીક કર્યું, પરંતુ અવશેષો રહી ગયા.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

દિવસ #311: પરીક્ષણોને ઝડપી બનાવવું

સમય જતાં, ત્યાં વધુ પરીક્ષણો થયા, બિલ્ડ્સ ધીમી ચાલી, સૌથી ખરાબ કિસ્સામાં એક કલાક સુધી. રેટ્રોમાંના એક પર એક વાક્ય હતું "તે સારું છે કે ત્યાં પરીક્ષણો છે, પરંતુ તે ધીમા છે." પરિણામે, અમે વર્ચ્યુઅલ મશીનો પર સંકલન પરીક્ષણો છોડી દીધા અને તેને ઝડપી બનાવવા માટે તેને ડોકર માટે સ્વીકાર્યું. ઉપયોગમાં લેવાતા ટૂલ્સની સંખ્યા ઘટાડવા માટે અમે ટેસ્ટિનફ્રાને જવાબી વેરિફાયર સાથે પણ બદલ્યું છે.

કડક શબ્દોમાં કહીએ તો, ત્યાં પગલાંનો સમૂહ હતો:

ડોકર પર સ્વિચ કરો.
ભૂમિકા પરીક્ષણ દૂર કરો, જે નિર્ભરતાને કારણે ડુપ્લિકેટ છે.
ગુલામોની સંખ્યામાં વધારો.
ટેસ્ટ રન ઓર્ડર.
લિન્ટ કરવાની ક્ષમતા બધા સ્થાનિક રીતે એક આદેશ સાથે.

પરિણામે જેનકિન્સ પરની પાઇપલાઇન પણ એકીકૃત થઇ હતી

બિલ્ડ તબક્કાઓ બનાવો.
બધાને સમાંતરમાં લીંટ કરો.
ટેસ્ટ રોલ સ્ટેજ સમાંતર ચલાવો.
સમાપ્ત કરો

પાઠ શીખ્યા

વૈશ્વિક ચલો ટાળો

Ansible વૈશ્વિક ચલોનો ઉપયોગ કરે છે, ફોર્મમાં આંશિક ઉકેલ છે ખાનગી_ભૂમિકા_વાર, પરંતુ આ એક રામબાણ ઉપાય નથી.

ચાલો હું તમને એક ઉદાહરણ આપું. ચાલો role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

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

ખરાબ: વૈશ્વિક ચલનો ઉપયોગ કરો.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

સારું: વી defaults જરૂરી ચલોને વ્યાખ્યાયિત કરો અને પછીથી ફક્ત તેનો ઉપયોગ કરો.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

ઉપસર્ગ ભૂમિકા ચલો

ખરાબ: વૈશ્વિક ચલનો ઉપયોગ કરો.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

સારું: ચલોની ભૂમિકાઓમાં, ભૂમિકાના નામ સાથે ઉપસર્ગવાળા ચલોનો ઉપયોગ કરો; આ, ઇન્વેન્ટરી જોઈને, શું થઈ રહ્યું છે તે સમજવામાં સરળ બનાવશે.

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

લૂપ કંટ્રોલ વેરીએબલનો ઉપયોગ કરો

ખરાબ: લૂપ્સમાં પ્રમાણભૂત ચલનો ઉપયોગ કરો item, જો આ કાર્ય/પ્લેબુક ક્યાંક સમાવવામાં આવેલ છે, તો આ અણધારી વર્તન તરફ દોરી શકે છે

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

સારું: દ્વારા લૂપમાં ચલને ફરીથી વ્યાખ્યાયિત કરો loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

ઇનપુટ ચલો તપાસો

અમે ચલ ઉપસર્ગનો ઉપયોગ કરવા સંમત થયા છીએ; તે તપાસવું અનાવશ્યક રહેશે નહીં કે તેઓ અમારી અપેક્ષા મુજબ વ્યાખ્યાયિત કરવામાં આવ્યા છે અને, ઉદાહરણ તરીકે, ખાલી મૂલ્ય દ્વારા ઓવરરાઇડ કરવામાં આવ્યા નથી.

સારું: ચલો તપાસો.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

હેશ ડિક્શનરી ટાળો, ફ્લેટ સ્ટ્રક્ચરનો ઉપયોગ કરો

જો કોઈ ભૂમિકા તેના પરિમાણોમાંના એકમાં હેશ/શબ્દકોષની અપેક્ષા રાખે છે, તો જો આપણે ચાઈલ્ડ પેરામીટર્સમાંના એકને બદલવા માંગીએ છીએ, તો અમારે સમગ્ર હેશ/શબ્દકોષને ઓવરરાઈડ કરવાની જરૂર પડશે, જે રૂપરેખાંકનની જટિલતાને વધારશે.

ખરાબ: હેશ/શબ્દકોષનો ઉપયોગ કરો.

---
user:
  name: admin
  group: admin

સારું: ફ્લેટ વેરીએબલ સ્ટ્રક્ચરનો ઉપયોગ કરો.

---
user_name: admin
user_group: "{{ user_name }}"

નિર્દોષ પ્લેબુક અને ભૂમિકાઓ બનાવો

ભૂમિકાઓ અને પ્લેબુક્સ નિર્દોષ હોવા જ જોઈએ, કારણ કે રૂપરેખાંકન ડ્રિફ્ટ અને કંઈક તૂટવાનો ડર ઘટાડે છે. પરંતુ જો તમે પરમાણુનો ઉપયોગ કરો છો, તો આ મૂળભૂત વર્તન છે.

આદેશ શેલ મોડ્યુલોનો ઉપયોગ કરવાનું ટાળો

શેલ મોડ્યુલનો ઉપયોગ કરવાથી ઘોષણાત્મકને બદલે અનિવાર્ય વર્ણનના દાખલામાં પરિણમે છે, જે જવાબીબલનો મુખ્ય ભાગ છે.

પરમાણુ દ્વારા તમારી ભૂમિકાઓનું પરીક્ષણ કરો

મોલેક્યુલ એ ખૂબ જ લવચીક વસ્તુ છે, ચાલો થોડા દૃશ્યો જોઈએ.

પરમાણુ બહુવિધ ઉદાહરણો

В molecule.yml વિભાગમાં platforms તમે ઘણા યજમાનોનું વર્ણન કરી શકો છો જેને તમે જમાવી શકો છો.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

તદનુસાર, આ યજમાનો પછી હોઈ શકે છે converge.yml વાપરવુ:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

જવાબી ચકાસણીકર્તા

પરમાણુમાં ઇન્સ્ટન્સ યોગ્ય રીતે ગોઠવવામાં આવ્યું છે કે નહીં તે તપાસવા માટે જવાબીબલનો ઉપયોગ કરવો શક્ય છે, વધુમાં, રિલીઝ 3 થી આ ડિફોલ્ટ છે. તે ટેસ્ટિનફ્રા/ઇન્સપેક જેટલું લવચીક નથી, પરંતુ અમે ચકાસી શકીએ છીએ કે ફાઇલની સામગ્રી અમારી અપેક્ષાઓ સાથે મેળ ખાય છે:

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

અથવા સેવાનો ઉપયોગ કરો, તે ઉપલબ્ધ થવાની રાહ જુઓ અને ધૂમ્રપાન પરીક્ષણ કરો:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

જટિલ તર્કને મોડ્યુલો અને પ્લગિન્સમાં મૂકો

જવાબ આપનાર ઘોષણાત્મક અભિગમની હિમાયત કરે છે, તેથી જ્યારે તમે કોડ બ્રાન્ચિંગ, ડેટા ટ્રાન્સફોર્મેશન, શેલ મોડ્યુલ્સ કરો છો, ત્યારે કોડ વાંચવો મુશ્કેલ બની જાય છે. આનો સામનો કરવા અને સમજવામાં સરળ રાખવા માટે, તમારા પોતાના મોડ્યુલો બનાવીને આ જટિલતાનો સામનો કરવો અનાવશ્યક રહેશે નહીં.

ટિપ્સ અને યુક્તિઓનો સારાંશ આપો

વૈશ્વિક ચલો ટાળો.
ઉપસર્ગ ભૂમિકા ચલો.
લૂપ કંટ્રોલ વેરીએબલનો ઉપયોગ કરો.
ઇનપુટ ચલો તપાસો.
હેશ ડિક્શનરી ટાળો, ફ્લેટ સ્ટ્રક્ચરનો ઉપયોગ કરો.
નિર્દોષ પ્લેબુક અને ભૂમિકાઓ બનાવો.
આદેશ શેલ મોડ્યુલોનો ઉપયોગ કરવાનું ટાળો.
પરમાણુ દ્વારા તમારી ભૂમિકાઓનું પરીક્ષણ કરો.
જટિલ તર્કને મોડ્યુલો અને પ્લગિન્સમાં મૂકો.

નિષ્કર્ષ

તમે ફક્ત જઈને કોઈ પ્રોજેક્ટ પર ઈન્ફ્રાસ્ટ્રક્ચર રિફેક્ટ કરી શકતા નથી, પછી ભલે તમારી પાસે IaC હોય. આ એક લાંબી પ્રક્રિયા છે જેમાં ધીરજ, સમય અને જ્ઞાનની જરૂર હોય છે.

કડીઓ

UPD1 2020.05.01 20:30 - પ્લેબુકની પ્રાથમિક રૂપરેખા માટે તમે ઉપયોગ કરી શકો છો callback_whitelist = profile_tasks લાંબા સમય માટે બરાબર શું કામ કરે છે તે સમજવા માટે. પછી આપણે પસાર થઈએ છીએ જવાબી પ્રવેગક ક્લાસિક્સ. તમે પણ પ્રયાસ કરી શકો છો મિટોજન
UPD2 2020.05.03 16:34 - ઇંગલિશ આવૃત્તિ

સોર્સ: www.habr.com

પરીક્ષણ કેવી રીતે શરૂ કરવું એન્સિબલ, એક વર્ષમાં પ્રોજેક્ટને રિફેક્ટર કરો અને પાગલ ન થાઓ