🥇Ինչպես սկսել Ansible-ի թեստավորումը, մեկ տարում վերամշակել նախագիծը և չխելագարվել

Սա սղագրությունն է ներկայացումներ մասին DevOps-40 2020-03-18:

Երկրորդ commit-ից սկսած ցանկացած կոդ դառնում է ժառանգություն, քանի որ սկզբնական գաղափարները սկսում են շեղվել դաժան իրականությունից: Սա ոչ լավ է, ոչ վատ, դա տրված է, որի հետ դժվար է վիճել և պետք է ապրել դրա հետ։ Այս գործընթացի մի մասը վերամշակումն է: Ենթակառուցվածքի վերամշակում որպես օրենսգիրք: Թող պատմությունը սկսվի այն մասին, թե ինչպես կարելի է վերամշակել Ansible-ը մեկ տարում և չխելագարվել:

Ժառանգության ծնունդը

Օր թիվ 1. Զրո հիվանդ

Ժամանակին պայմանական նախագիծ կար. Այն ուներ Dev-ի մշակման թիմ և Ops-ի ինժեներներ: Նրանք լուծում էին նույն խնդիրը՝ ինչպես տեղադրել սերվերներ և գործարկել հավելված: Խնդիրն այն էր, որ յուրաքանչյուր թիմ յուրովի լուծեց այս խնդիրը։ Նախագծում որոշվեց օգտագործել Ansible-ը Dev և Ops թիմերի միջև գիտելիքները համաժամեցնելու համար:

Օր #89. Ժառանգության ծնունդը

Նրանք իրենք էլ չնկատելով դա՝ ցանկանում էին դա անել հնարավորինս լավ, բայց ստացվեց ժառանգություն։ Ինչպե՞ս է դա տեղի ունենում:

Մենք այստեղ հրատապ խնդիր ունենք, արի մի կեղտոտ հաքեր անենք, հետո շտկենք։
Պետք չէ փաստաթղթեր գրել, և ամեն ինչ պարզ է, թե ինչ է կատարվում այստեղ:
Ես գիտեմ Ansible/Python/Bash/Terraform! Տեսեք, թե ինչպես կարող եմ խուսափել.
Ես Full Stack Overflow ծրագրավորող եմ և պատճենել եմ սա stackoverflow-ից, չգիտեմ, թե ինչպես է այն աշխատում, բայց այն հիանալի տեսք ունի և լուծում է խնդիրը:

Արդյունքում, դուք կարող եք ստանալ անհասկանալի կոդ, որի համար փաստաթղթեր չկան, պարզ չէ, թե դա ինչ է անում, արդյոք դա անհրաժեշտ է, բայց խնդիրն այն է, որ դուք պետք է մշակեք այն, փոփոխեք այն, ավելացնեք հենակներ և հենարաններ: , էլ ավելի վատթարացնելով իրավիճակը։

- 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. Վերագործարկման նախապատրաստում

Առաջին բանը պատրաստելն է. Որոշեք, թե ինչ ենք անելու։ Դա անելու համար մենք շփվում ենք, գտնում ենք խնդրահարույց ոլորտներ և պարզում դրանց լուծման ուղիները: Մենք ինչ-որ կերպ արձանագրում ենք ստացված հասկացությունները, օրինակ՝ հոդվածը համահունչ, որպեսզի երբ հարց առաջանա՝ «ի՞նչն է լավագույնը»: կամ «որն է ճիշտ»: Մենք չենք կորցրել մեր ճանապարհը. Մեր դեպքում մենք մնացինք գաղափարին բաժանիր և տիրիրՄենք բաժանում ենք ենթակառուցվածքը փոքր կտորների/աղյուսների: Այս մոտեցումը թույլ է տալիս վերցնել ենթակառուցվածքի մեկուսացված հատվածը, հասկանալ, թե ինչ է այն անում, ծածկել այն թեստերով և փոխել այն՝ չվախենալով որևէ բան կոտրելուց:

Ստացվում է, որ ենթակառուցվածքների փորձարկումը դառնում է հիմնաքար, և այստեղ հարկ է նշել ենթակառուցվածքների փորձարկման բուրգը։ Հենց նույն գաղափարը, որը մշակման փուլում է, բայց ենթակառուցվածքի համար. մենք անցնում ենք էժան արագ թեստերից, որոնք ստուգում են պարզ բաները, օրինակ՝ մատնանշումը, դեպի թանկարժեք լիարժեք թեստեր, որոնք տեղակայում են ամբողջ ենթակառուցվածքը:

Անզգայուն փորձարկման փորձեր

Նախքան նկարագրելու, թե ինչպես ենք մենք ծածկել Ansible թեստերը նախագծի վրա, ես նկարագրելու եմ այն փորձերն ու մոտեցումները, որոնք ես հնարավորություն ունեցա օգտագործել ավելի վաղ՝ հասկանալու համար ընդունված որոշումների ենթատեքստը:

Օր թիվ -997. SDS տրամադրում

Առաջին անգամ ես փորձարկեցի Ansible-ը SDS (Ծրագրային ապահովման սահմանված պահեստ) մշակելու նախագծի վրա: Այս թեմայով կա առանձին հոդված
Ինչպես կոտրել հեծանիվները հենակներով, երբ փորձարկում եք ձեր բաշխումը, բայց մի խոսքով, մենք վերջացրինք շրջված թեստային բուրգի և փորձարկման համար մեկ դերի վրա ծախսեցինք 60-90 րոպե, ինչը երկար ժամանակ է: Հիմքը e2e թեստերն էին, այսինքն. մենք տեղակայեցինք լիարժեք տեղադրում, այնուհետև փորձարկեցինք այն: Առավել ծանրացուցիչը սեփական հեծանիվի գյուտն էր։ Բայց պետք է խոստովանեմ, որ այս լուծումն աշխատեց և թույլ տվեց կայուն թողարկում:

Օր # -701. Անվտանգ և փորձնական խոհանոց

Ansible-ի թեստավորման գաղափարի զարգացումը եղել է պատրաստի գործիքների օգտագործումը, այն է՝ թեստային խոհանոց/խոհանոց-ci և inspect: Ընտրությունը որոշվել է Ռուբիի իմացությամբ (մանրամասների համար տե՛ս Habré-ի հոդվածը. Արդյո՞ք YML ծրագրավորողները երազում են Ansible-ի փորձարկման մասին:) աշխատել է ավելի արագ՝ մոտ 40 րոպե 10 դերի համար։ Մենք ստեղծեցինք վիրտուալ մեքենաների փաթեթ և փորձարկումներ կատարեցինք ներսում:

Ընդհանուր առմամբ լուծույթն աշխատել է, բայց տարասեռության պատճառով որոշակի նստվածք է եղել։ Երբ փորձարկված մարդկանց թիվը հասցվեց 13 հիմնական դերերի և 2 մետա դերերի՝ միավորելով ավելի փոքր դերերը, հետո հանկարծ թեստերը սկսեցին տևել 70 րոպե, ինչը գրեթե 2 անգամ ավելի երկար է: Դժվար էր խոսել XP (ծայրահեղ ծրագրավորման) պրակտիկայի մասին, քանի որ... ոչ ոք չի ցանկանում սպասել 70 րոպե: Սա էր մոտեցումը փոխելու պատճառը

Օր # -601. Անզգայուն և մոլեկուլ

Հայեցակարգային առումով սա նման է թեստային խոհանոցին, միայն մենք դերերի թեստավորումը տեղափոխեցինք դոկեր և փոխեցինք փաթեթը: Արդյունքում ժամանակը կրճատվել է 20 դերերի համար կայուն 25-7 րոպեի։

Փորձարկված դերերի քանակը հասցնելով 17-ի և 45 դերերի վրա՝ մենք սա գործարկեցինք 28 րոպեում 2 ջենկինս ստրուկների վրա:

Օր #167. Նախագծին Ansible թեստերի ավելացում

Ամենայն հավանականությամբ, հապճեպ հնարավոր չի լինի կատարել վերամշակման խնդիրը: Առաջադրանքը պետք է չափելի լինի, որպեսզի կարողանաս մանր կտորների բաժանել ու թեյի գդալով մաս առ մաս ուտես փղին։ Պետք է լինի հասկացողություն, թե արդյոք ճիշտ ուղղությամբ եք շարժվում, ինչքա՞ն պետք է գնալ։

Ընդհանրապես, կարևոր չէ, թե ինչպես դա կկատարվի, կարող եք գրել թղթի վրա, կարող եք կպչուն պիտակներ դնել պահարանի վրա, կարող եք առաջադրանքներ ստեղծել Jira-ում, կամ կարող եք բացել Google Docs-ը և գրել ընթացիկ կարգավիճակը: այնտեղ։ Ոտքերը աճում են նրանից, որ գործընթացն անմիջական չէ, այն երկար ու հոգնեցուցիչ կլինի։ Քիչ հավանական է, որ ինչ-որ մեկը ցանկանա, որ վերամշակման ընթացքում դուք այրվեք գաղափարներից, հոգնեք և ծանրաբեռնվեք:

Վերամշակումը պարզ է.

Ուտում:
Քնել
Կոդ
IaC թեստ.
Կրկնել

և դա կրկնում ենք այնքան, մինչև հասնենք նպատակին։

Հնարավոր է, որ հնարավոր չլինի անմիջապես սկսել ամեն ինչ փորձարկել, ուստի մեր առաջին խնդիրն էր սկսել linting-ով և ստուգելով շարահյուսությունը:

Օր #181. Կանաչ շինարարության վարպետ

Linting-ը փոքր առաջին քայլն է դեպի Green Build Master: Սա գրեթե ոչինչ չի կոտրի, բայց թույլ կտա վրիպազերծել գործընթացները և կանաչ կառուցումներ կատարել Ջենքինսում: Գաղափարը թիմում սովորություններ զարգացնելն է.

Կարմիր թեստերը վատ են:
Ես եկել եմ ինչ-որ բան շտկելու և միևնույն ժամանակ ծածկագիրը մի փոքր ավելի լավը դարձնելու, քան քո առաջ էր։

Օր #193. Լինտինգից մինչև միավորի թեստեր

Կոդը վարպետի մեջ ներդնելու գործընթացը կառուցելով, կարող եք սկսել քայլ առ քայլ կատարելագործման գործընթացը՝ ծածկույթը փոխարինելով մեկնարկային դերերով, դուք նույնիսկ կարող եք դա անել առանց անզորության: Դուք պետք է հասկանաք, թե ինչպես կիրառել դերերը և ինչպես են դրանք աշխատում:

Օր #211. միավորից մինչև ինտեգրացիոն թեստեր

Երբ դերերի մեծ մասը ծածկված է միավորի թեստերով, և ամեն ինչ ծածկված է, կարող եք անցնել ինտեգրացիոն թեստերի ավելացմանը: Նրանք. ենթակառուցվածքում ոչ թե մեկ աղյուսի փորձարկում, այլ դրանց համակցություն, օրինակ՝ ամբողջական օրինակի կոնֆիգուրացիա:

Ջենկինների օգնությամբ մենք ստեղծեցինք բազմաթիվ փուլեր, որոնք զուգահեռաբար փակցնում էին դերերը/գրքույկները, այնուհետև միավորային թեստերը տարաներում և վերջապես ինտեգրման թեստերը:

Jenkins + Docker + Ansible = Թեստեր

Ստուգեք ռեպո և ստեղծեք կառուցման փուլեր:
Զուգահեռաբար գործարկեք lint playbook փուլերը:
Զուգահեռաբար վարեք լինտի դերի փուլերը:
Զուգահեռաբար գործարկել շարահյուսության ստուգման դերի փուլերը:
Զուգահեռաբար կատարեք թեստային դերի փուլերը:
1. Լինտի դերը.
2. Ստուգեք կախվածությունը այլ դերերից:
3. Ստուգեք շարահյուսությունը:
4. Ստեղծեք դոկերի օրինակ
5. Գործարկել molecule/default/playbook.yml.
6. Ստուգեք անզորությունը.
Կատարեք ինտեգրման թեստեր
Ավարտել

Օր #271. Ավտոբուսի գործոն

Սկզբում ռեֆակտորինգն իրականացվում էր երկու-երեք հոգուց բաղկացած փոքր խմբի կողմից։ Նրանք վերանայեցին կոդը վարպետի մեջ: Ժամանակի ընթացքում թիմը զարգացրեց գիտելիքներ կոդ գրելու և կոդերի վերանայման վերաբերյալ, ինչը նպաստեց ենթակառուցվածքի և դրա աշխատանքի մասին գիտելիքների տարածմանը: Այստեղ ամենակարևորն այն էր, որ գրախոսները մեկ առ մեկ ընտրվում էին ըստ ժամանակացույցի, այսինքն. որոշ աստիճանի հավանականությամբ դուք կբարձրանաք նոր ենթակառուցվածքի մեջ:

Եվ այստեղ պետք է հարմարավետ լինի: Հարմար է վերանայում անել, տեսնել, թե ինչ առաջադրանքի շրջանակներում է արվել, և քննարկումների պատմությունը։ Մենք ունենք ինտեգրված jenkins + bitbucket + jira:

Բայց որպես այդպիսին, վերանայումը համադարման միջոց չէ, ինչ-որ կերպ մենք մտանք հիմնական կոդը, որը մեզ ստիպեց ֆլոպ թեստեր.

- 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. թեստերի արագացում

Ժամանակի ընթացքում ավելի շատ թեստեր եղան, շինությունները ավելի դանդաղ էին աշխատում, վատագույն դեպքում մինչև մեկ ժամ: Ռետրոներից մեկի վրա կար արտահայտություն, ինչպիսին է «լավ է, որ թեստեր կան, բայց դրանք դանդաղ են»: Արդյունքում, մենք հրաժարվեցինք վիրտուալ մեքենաների վրա ինտեգրման թեստերից և հարմարեցրինք դրանք Docker-ի համար՝ այն ավելի արագ դարձնելու համար: Մենք նաև փոխարինեցինք testinfra-ն անխափան ստուգիչով՝ օգտագործվող գործիքների քանակը նվազեցնելու համար:

Խիստ ասած, կար մի շարք միջոցառումներ.

Անցում դոկերին:
Հեռացրեք դերերի փորձարկումը, որը կրկնօրինակված է կախվածության պատճառով:
Բարձրացնել ստրուկների թիվը:
Փորձարկման կարգը.
Թիթեղավորելու ունակություն ԲՈԼՈՐ տեղական մեկ հրամանով.

Արդյունքում, Ջենկինների վրա խողովակաշարը նույնպես միավորվեց

Ստեղծեք կառուցման փուլեր:
Lint բոլորը զուգահեռ.
Զուգահեռաբար կատարեք թեստային դերի փուլերը:
Ավարտել.

Դասերը

Խուսափեք գլոբալ փոփոխականներից

Ansible-ն օգտագործում է գլոբալ փոփոխականներ, ձևի մեջ կա մասնակի լուծում private_role_vars, բայց սա համադարման չէ։

Մի օրինակ բերեմ. Թույլ տվեք ունենալ 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

ԼԱՎ: V 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 }}"

Ստեղծեք անիմաստ խաղային գրքեր և դերեր

Դերերն ու խաղատախտակները պետք է լինեն անիմաստ, քանի որ նվազեցնում է կոնֆիգուրացիայի շեղումը և ինչ-որ բան կոտրելու վախը: Բայց եթե դուք օգտագործում եք մոլեկուլ, ապա սա լռելյայն վարքագիծ է:

Խուսափեք հրամանի վահանակի մոդուլներ օգտագործելուց

Կեղևի մոդուլի օգտագործումը հանգեցնում է նկարագրության հրամայական պարադիգմի, այլ ոչ թե դեկլարատիվ, որը Ansible-ի առանցքն է:

Փորձեք ձեր դերերը մոլեկուլի միջոցով

Մոլեկուլը շատ ճկուն բան է, եկեք դիտարկենք մի քանի սցենար։

Մոլեկուլ Բազմաթիվ օրինակներ

В 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

Անհստակ ստուգիչ

Մոլեկուլում հնարավոր է օգտագործել ansible՝ ստուգելու համար, որ օրինակը ճիշտ է կազմաձևվել, ավելին, սա լռելյայն էր 3-րդ թողարկումից ի վեր: Այն այնքան ճկուն չէ, որքան testinfra/inspec-ը, բայց մենք կարող ենք ստուգել, որ ֆայլի բովանդակությունը համապատասխանում է մեր ակնկալիքներին.

---
- 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

Տեղադրեք բարդ տրամաբանություն մոդուլների և պլագինների մեջ

Ansible-ը պաշտպանում է դեկլարատիվ մոտեցում, այնպես որ, երբ դուք կատարում եք կոդի ճյուղավորում, տվյալների փոխակերպում, կեղևի մոդուլներ, կոդը դժվարանում է կարդալ: Դրա դեմ պայքարելու և հասկանալի համար պարզ պահելու համար ավելորդ չի լինի պայքարել այս բարդության դեմ՝ ստեղծելով ձեր սեփական մոդուլները:

Ամփոփել խորհուրդներ և հնարքներ

Խուսափեք գլոբալ փոփոխականներից:
Նախածանցի դերի փոփոխականներ:
Օգտագործեք հանգույցի կառավարման փոփոխական:
Ստուգեք մուտքագրման փոփոխականները:
Խուսափեք հեշային բառարաններից, օգտագործեք հարթ կառուցվածք:
Ստեղծեք անիմաստ խաղային գրքեր և դերեր:
Խուսափեք հրամանի վահանակի մոդուլներ օգտագործելուց:
Փորձեք ձեր դերերը մոլեկուլի միջոցով:
Տեղադրեք բարդ տրամաբանություն մոդուլների և պլագինների մեջ:

Ամփոփում

Դուք չեք կարող պարզապես գնալ և վերափոխել ենթակառուցվածքը նախագծի վրա, նույնիսկ եթե ունեք IaC: Սա երկար գործընթաց է, որը պահանջում է համբերություն, ժամանակ և գիտելիքներ։

հղումներ

UPD1 2020.05.01 20:30 — Խաղագրքերի առաջնային պրոֆիլավորման համար կարող եք օգտագործել callback_whitelist = profile_tasks հասկանալ, թե կոնկրետ ինչն է աշխատում երկար ժամանակ: Հետո անցնում ենք Ansible արագացման դասականներ. Կարող եք նաև փորձել միտոգեն
UPD2 2020.05.03 16:34 - անգլերեն տարբերակ

Source: www.habr.com

Ինչպես սկսել Ansible-ի փորձարկումները, մեկ տարում վերամշակել նախագիծը և չխելագարվել