როგორ დავიწყოთ Ansible-ის ტესტირება, გადააკეთეთ პროექტი ერთ წელიწადში და არ გაგიჟდეთ

ეს არის ჩანაწერი სპექტაკლები on DevOps-40 2020-03-18:

მეორე კომიტიდან დაწყებული, ნებისმიერი კოდი ხდება მემკვიდრეობა, რადგან თავდაპირველი იდეები იწყებს უხეში რეალობისგან განსხვავებას. ეს არც კარგია და არც ცუდი, ეს არის მოცემულობა, რომელთანაც კამათი რთულია და უნდა იცხოვრო. ამ პროცესის ნაწილია რეფაქტორირება. Refactoring ინფრასტრუქტურა როგორც კოდი. დაე, დაიწყოს ისტორია იმის შესახებ, თუ როგორ უნდა მოხდეს 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: ნამდვილად გჭირდებათ რეფაქტორირება?

სანამ რეფაქტორზე იჩქარებთ, თქვენ უნდა უპასუხოთ რამდენიმე მნიშვნელოვან კითხვას:

1. რატომ გჭირდება ეს ყველაფერი?
2. დრო გაქვს?
3. საკმარისია თუ არა ცოდნა?

თუ არ იცით როგორ უპასუხოთ კითხვებს, მაშინ რეფაქტორირება დასრულდება მანამ, სანამ ის დაიწყება, ან შეიძლება გაუარესდეს. იმიტომ რომ გამოცდილება მქონდა ( რა ვისწავლე ინფრასტრუქტურის კოდის 200 ხაზის ტესტირებიდან), შემდეგ პროექტმა მიიღო დახმარება როლების დაფიქსირებისა და ტესტებით დაფარვისთვის.

დღე #149: რეფაქტორინგის მომზადება

პირველი რაც არის მომზადება. გადაწყვიტეთ რას გავაკეთებთ. ამისათვის ჩვენ ვუკავშირდებით, ვპოულობთ პრობლემურ სფეროებს და ვხვდებით მათი გადაჭრის გზებს. ჩვენ ვწერთ მიღებულ ცნებებს როგორღაც, მაგალითად, სტატიის შერწყმაში, ისე, რომ როდესაც ჩნდება კითხვა "რა არის საუკეთესო?" ან "რა არის სწორი?" გზა არ დაგვიკარგავს. ჩვენს შემთხვევაში, ჩვენ დავრჩით იდეაზე გაყავი და იბატონე: ჩვენ ვყოფთ ინფრასტრუქტურას პატარა ნაჭრებად/აგურებად. ეს მიდგომა საშუალებას გაძლევთ აიღოთ ინფრასტრუქტურის იზოლირებული ნაწილი, გაიგოთ რას აკეთებს ის, დაფაროთ იგი ტესტებით და შეცვალოთ იგი არაფრის დარღვევის შიშის გარეშე.

გამოდის, რომ ინფრასტრუქტურის ტესტირება ხდება ქვაკუთხედი და აქ აღსანიშნავია ინფრასტრუქტურის ტესტირების პირამიდა. ზუსტად იგივე იდეა, რომელიც დამუშავების პროცესშია, მაგრამ ინფრასტრუქტურისთვის: ჩვენ გადავდივართ იაფი სწრაფი ტესტებიდან, რომლებიც ამოწმებს მარტივ რაღაცეებს, როგორიცაა ჩაღრმავება, ძვირადღირებულ სრულფასოვან ტესტებზე, რომლებიც ავრცელებენ მთელ ინფრასტრუქტურას.

პასუხისმგებელი ტესტირების მცდელობები

სანამ ჩვენ აღვწერთ, თუ როგორ გავაშუქეთ Ansible ტესტები პროექტზე, მე აღვწერ მცდელობებსა და მიდგომებს, რომლებიც ადრე მქონდა საშუალება გამომეყენებინა მიღებული გადაწყვეტილებების კონტექსტის გასაგებად.

დღე No -997: SDS უზრუნველყოფა

პირველად გავტესტე Ansible იყო SDS-ის (პროგრამული უზრუნველყოფის განსაზღვრული საცავი) შემუშავების პროექტზე. ამ თემაზე ცალკე სტატიაა
როგორ გავტეხოთ ველოსიპედები ხელჯოხებით თქვენი განაწილების ტესტირებისას, მაგრამ მოკლედ, შებრუნებული ტესტირების პირამიდა დავასრულეთ და ტესტირება ერთ როლზე დავხარჯეთ 60-90 წუთი, რაც დიდი დროა. საფუძველი იყო e2e ტესტები, ე.ი. ჩვენ განვათავსეთ სრულფასოვანი ინსტალაცია და შემდეგ გამოვცადეთ იგი. კიდევ უფრო დამამძიმებელი იყო საკუთარი ველოსიპედის გამოგონება. მაგრამ უნდა ვაღიარო, რომ ამ გამოსავალმა იმუშავა და სტაბილური გამოშვების საშუალება მისცა.

დღე # -701: სტაციონარული და სატესტო სამზარეულო

Ansible ტესტირების იდეის განვითარება იყო მზა ხელსაწყოების გამოყენება, კერძოდ, სატესტო სამზარეულო / სამზარეულო-ცი და ინსპექცია. არჩევანი განისაზღვრა რუბის ცოდნით (დამატებითი ინფორმაციისთვის იხილეთ სტატია ჰაბრეზე: ოცნებობენ თუ არა YML პროგრამისტები Ansible-ის ტესტირებაზე?) მუშაობდა უფრო სწრაფად, დაახლოებით 40 წუთი 10 როლისთვის. ჩვენ შევქმენით ვირტუალური მანქანების პაკეტი და ჩავატარეთ ტესტები შიგნით.

ზოგადად, ხსნარი მუშაობდა, მაგრამ იყო ნალექი ჰეტეროგენურობის გამო. როდესაც ტესტირებული ადამიანების რაოდენობა გაიზარდა 13 ძირითად როლამდე და 2 მეტა როლამდე, რომლებიც აერთიანებდა უფრო მცირე როლებს, მაშინ მოულოდნელად ტესტები დაიწყო 70 წუთის განმავლობაში, რაც თითქმის 2-ჯერ მეტია. XP (ექსტრემალური პროგრამირების) პრაქტიკაზე საუბარი რთული იყო, რადგან... არავის არ სურს 70 წუთის ლოდინი. ეს იყო მიდგომის შეცვლის მიზეზი

დღე # -601: ანსიბული და მოლეკულა

კონცეპტუალურად, ეს ტესტის სამზარეულოს მსგავსია, მხოლოდ ჩვენ გადავიტანეთ როლური ტესტირება დოკერზე და შევცვალეთ სტეკი. შედეგად, დრო შემცირდა სტაბილურ 20-25 წუთამდე 7 როლისთვის.

შემოწმებული როლების რიცხვის 17-მდე გაზრდით და 45 როლის მინიჭებით, ჩვენ ეს გავატარეთ 28 წუთში 2 jenkins slave-ზე.

დღე #167: პროექტში Ansible ტესტების დამატება

დიდი ალბათობით, შეუძლებელი იქნება რეფაქტორის ამოცანის დაჩქარება. დავალება უნდა იყოს გაზომვადი ისე, რომ წვრილად გატეხოთ და სპილოს ნაწილ-ნაწილ ჭამოთ ჩაის კოვზით. უნდა არსებობდეს იმის გაგება, მიდიხარ თუ არა სწორი მიმართულებით, რამდენ ხანს უნდა წახვიდე.

ზოგადად, არ აქვს მნიშვნელობა როგორ გაკეთდება, შეგიძლიათ დაწეროთ ფურცელზე, შეგიძლიათ კარადაზე სტიკერები დაადოთ, ჯირაში შექმნათ ამოცანები, ან შეგიძლიათ გახსნათ Google Docs და ჩაწეროთ მიმდინარე სტატუსი. იქ. ფეხები იზრდება იმის გამო, რომ პროცესი არ არის მყისიერი, ეს იქნება ხანგრძლივი და დამღლელი. ნაკლებად სავარაუდოა, რომ ვინმეს სურდეს, რომ გადაიწვიოთ იდეებით, დაიღალოთ და გადატვირთოთ რეფაქტორირების დროს.

რეფაქტორირება მარტივია:

• ჭამა.
• ძილის.
• კოდექსი.
• IaC ტესტი.
• გაიმეორეთ

და ჩვენ ვიმეორებთ ამას მანამ, სანამ არ მივაღწევთ დანიშნულ მიზანს.

შესაძლოა ყველაფრის დაუყოვნებლად დაწყება შეუძლებელი იყოს, ამიტომ ჩვენი პირველი ამოცანა იყო ლინტინგით და სინტაქსის შემოწმებით დაწყება.

დღე #181: Green Build Master

Linting არის პატარა პირველი ნაბიჯი Green Build Master-ისკენ. ეს თითქმის არაფერს დაარღვევს, მაგრამ საშუალებას მოგცემთ გამართოთ პროცესები და შექმნათ მწვანე ნაგებობები ჯენკინსში. იდეა არის გუნდში ჩვევების გამომუშავება:

• წითელი ტესტები ცუდია.
• მოვედი, რომ რაღაც გამოვასწორო და ამავდროულად გავაკეთო კოდი ცოტა უკეთესი ვიდრე შენამდე იყო.

დღე #193: ლაქიდან ერთეულ ტესტებამდე

კოდის მასტერში მოხვედრის პროცესის შედგენის შემდეგ, შეგიძლიათ დაიწყოთ ეტაპობრივი გაუმჯობესების პროცესი - შეცვალეთ ლაქები გაშვების როლებით, შეგიძლიათ ამის გაკეთებაც კი უძლურების გარეშე. თქვენ უნდა გესმოდეთ, როგორ გამოიყენოთ როლები და როგორ მუშაობენ ისინი.

დღე #211: ერთეულიდან ინტეგრაციის ტესტებამდე

როდესაც როლების უმეტესობა დაფარულია ერთეული ტესტებით და ყველაფერი დაფარულია, შეგიძლიათ გადახვიდეთ ინტეგრაციის ტესტების დამატებაზე. იმათ. ინფრასტრუქტურაში არც ერთი აგურის ტესტირება, არამედ მათი კომბინაცია, მაგალითად, სრული ინსტანციის კონფიგურაცია.

ჯენკინების გამოყენებით, ჩვენ შევქმენით მრავალი ეტაპი, რომლებიც პარალელურად ათავსებდნენ როლებს/სათამაშო წიგნებს, შემდეგ ერთეულების ტესტები კონტეინერებში და ბოლოს ინტეგრაციის ტესტები.

Jenkins + Docker + Ansible = ტესტები

1. შეამოწმეთ რეპო და შექმენით მშენებლობის ეტაპები.
2. პარალელურად გაუშვით lint playbook ეტაპები.
3. გაუშვით ლინტის როლის ეტაპები პარალელურად.
4. სინტაქსის შემოწმების როლის ეტაპების პარალელურად გაშვება.
5. პარალელურად გაუშვით ტესტის როლის ეტაპები.
   1. ლინტის როლი.
   2. შეამოწმეთ დამოკიდებულება სხვა როლებზე.
   3. შეამოწმეთ სინტაქსი.
   4. შექმენით დოკერის მაგალითი
   5. გაუშვით molecule/default/playbook.yml.
   6. შეამოწმეთ იმპოტენცია.
6. ჩაატარეთ ინტეგრაციის ტესტები
7. ფერი

დღე #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 ცალსახა გადამოწმებით, გამოყენებული ხელსაწყოების რაოდენობის შესამცირებლად.

მკაცრად რომ ვთქვათ, იყო ზომების მთელი რიგი:

1. დოკერზე გადართვა.
2. წაშალეთ როლების ტესტირება, რომელიც დუბლირებულია დამოკიდებულებების გამო.
3. გაზარდეთ მონების რაოდენობა.
4. სატესტო გაშვების შეკვეთა.
5. ლინტის უნარი ყველა ლოკალურად ერთი ბრძანებით.

შედეგად, Pipeline on jenkins ასევე გაერთიანდა

1. შექმენით მშენებლობის ეტაპები.
2. ლინტი ყველა პარალელურად.
3. პარალელურად გაუშვით ტესტის როლის ეტაპები.
4. დასრულება.

გაკვეთილების

მოერიდეთ გლობალურ ცვლადებს

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-ის ბუნება და საუკეთესო, რაც შეიძლება გაკეთდეს, არის რაიმე სახის შეთანხმების გამოყენება, მაგალითად, როლის ფარგლებში, გამოიყენეთ მხოლოდ ამ როლში აღწერილი ცვლადი.

BAD: გამოიყენეთ გლობალური ცვლადი.

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

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

პრეფიქსი როლის ცვლადები

BAD: გამოიყენეთ გლობალური ცვლადი.

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

GOOD: ცვლადების როლებში გამოიყენეთ ცვლადები როლის სახელთან პრეფიქსით; ეს, ინვენტარის დათვალიერებით, გააადვილებს იმის გაგებას, თუ რა ხდება.

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

გამოიყენეთ მარყუჟის კონტროლის ცვლადი

BAD: გამოიყენეთ სტანდარტული ცვლადი მარყუჟებში item, თუ ეს დავალება/სათამაშო წიგნი სადმე შედის, ამან შეიძლება გამოიწვიოს მოულოდნელი ქცევა

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

GOOD: ხელახლა განსაზღვრეთ ცვლადი მარყუჟში მეშვეობით loop_var.

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

შეამოწმეთ შეყვანის ცვლადები

ჩვენ შევთანხმდით ცვლადის პრეფიქსების გამოყენებაზე; ზედმეტი არ იქნებოდა იმის შემოწმება, რომ ისინი განსაზღვრულია ისე, როგორც ჩვენ ველოდებით და, მაგალითად, არ იყო გადაფარული ცარიელი მნიშვნელობით.

GOOD: შეამოწმეთ ცვლადები.

- 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

მოერიდეთ ჰეშის ლექსიკონებს, გამოიყენეთ ბრტყელი სტრუქტურა

თუ როლი ელის ჰეშის/ლექსიკონს მის ერთ-ერთ პარამეტრში, მაშინ თუ გვინდა შევცვალოთ ერთ-ერთი შვილობილი პარამეტრი, დაგვჭირდება მთელი ჰეშის/ლექსიკონის გადაფარვა, რაც გაზრდის კონფიგურაციის სირთულეს.

BAD: გამოიყენეთ ჰეში/ლექსიკონი.

---
user:
  name: admin
  group: admin

GOOD: გამოიყენეთ ბრტყელი ცვლადი სტრუქტურა.

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

შექმენით უიმედო სათამაშო წიგნები და როლები

როლები და სათამაშო წიგნები უძლური უნდა იყოს, რადგან ამცირებს კონფიგურაციის დრიფტს და რაღაცის გატეხვის შიშს. მაგრამ თუ იყენებთ მოლეკულას, მაშინ ეს ნაგულისხმევი ქცევაა.

მოერიდეთ ბრძანების გარსის მოდულების გამოყენებას

Shell მოდულის გამოყენება იწვევს იმპერატიული აღწერის პარადიგმას, ნაცვლად დეკლარაციულისა, რომელიც არის 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 მხარს უჭერს დეკლარაციულ მიდგომას, ასე რომ, როდესაც თქვენ აკეთებთ კოდის განშტოებას, მონაცემთა ტრანსფორმაციას, ჭურვის მოდულებს, კოდი რთულდება წასაკითხად. ამის საბრძოლველად და გასაგებად გასაგებად, ზედმეტი არ იქნება ამ სირთულესთან ბრძოლა საკუთარი მოდულების შექმნით.

შეაჯამეთ რჩევები და ხრიკები

1. მოერიდეთ გლობალურ ცვლადებს.
2. პრეფიქსი როლის ცვლადები.
3. გამოიყენეთ მარყუჟის კონტროლის ცვლადი.
4. შეამოწმეთ შეყვანის ცვლადები.
5. მოერიდეთ ჰეშის ლექსიკონებს, გამოიყენეთ ბრტყელი სტრუქტურა.
6. შექმენით უიმედო სათამაშო წიგნები და როლები.
7. მოერიდეთ ბრძანების გარსის მოდულების გამოყენებას.
8. შეამოწმეთ თქვენი როლები მოლეკულის საშუალებით.
9. ჩადეთ რთული ლოგიკა მოდულებსა და დანამატებში.

დასკვნა

თქვენ არ შეგიძლიათ უბრალოდ წახვიდეთ და განაახლოთ ინფრასტრუქტურა პროექტზე, მაშინაც კი, თუ გაქვთ IaC. ეს არის ხანგრძლივი პროცესი, რომელიც მოითხოვს მოთმინებას, დროსა და ცოდნას.

ბმულები

• სლაიდები როგორ გავასინჯოთ Ansible და არ გავგიჟდეთ
• ვიდეო როგორ გავასინჯოთ Ansible და არ გავგიჟდეთ
• რა ვისწავლე ინფრასტრუქტურის კოდის 200 ხაზის ტესტირებიდან
• პასუხი: 120 VM კონფიგურაციის მიგრაცია Coreos-დან Centos-ში 18 თვეში
• როგორ გავტეხოთ ველოსიპედები ხელჯოხებით თქვენი განაწილების ტესტირებისას
• დამიტესტეთ, შეგიძლიათ თუ არა YML პროგრამისტები Ansible-ის ტესტირებაზე?
• გასაოცარი IaC ტესტირების სტატიების, გამოსვლებისა და ბმულების სია
• ჯვარი პოსტი
• ინგლისური ვერსია

UPD1 2020.05.01 20:30 — სათამაშო წიგნების პირველადი პროფილირებისთვის შეგიძლიათ გამოიყენოთ callback_whitelist = profile_tasks იმის გაგება, თუ რა მუშაობს ზუსტად დიდი ხნის განმავლობაში. შემდეგ ჩვენ გავდივართ საგრძნობი აჩქარების კლასიკა. თქვენ ასევე შეგიძლიათ სცადოთ მიტოგენი
UPD2 2020.05.03 16:34 - ინგლისური ვერსია

წყარო: www.habr.com