🥇วิธีเริ่มทดสอบ Ansible ปรับโครงสร้างโครงการใหม่ในหนึ่งปีและไม่บ้า

นี่คือการถอดเสียง การแสดง บน DevOps-40 2020-03-18:

เริ่มต้นจากการคอมมิตครั้งที่สอง โค้ดใดๆ จะกลายเป็นแบบเดิม เนื่องจาก ความคิดเริ่มแรกเริ่มแตกต่างจากความเป็นจริงอันโหดร้าย นี่ไม่ใช่เรื่องดีหรือไม่ดี เป็นสิ่งที่ยากจะโต้แย้งและต้องปฏิบัติตาม ส่วนหนึ่งของกระบวนการนี้คือการปรับโครงสร้างใหม่ การปรับโครงสร้างโครงสร้างพื้นฐานใหม่เป็นโค้ด ให้เรื่องราวเริ่มต้นเกี่ยวกับวิธีการสร้าง 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 (Software Defined Storage) มีบทความแยกต่างหากในหัวข้อนี้
วิธีหักจักรยานบนไม้ค้ำเมื่อทดสอบการกระจายตัวของคุณแต่โดยสรุปแล้ว เราจบลงด้วยปิรามิดการทดสอบแบบกลับหัว และการทดสอบเราใช้เวลา 60-90 นาทีในบทบาทเดียว ซึ่งถือว่าใช้เวลานาน พื้นฐานคือการทดสอบ e2e เช่น เราปรับใช้การติดตั้งแบบเต็มรูปแบบและทำการทดสอบแล้ว สิ่งที่เลวร้ายยิ่งกว่านั้นคือการประดิษฐ์จักรยานของเขาเอง แต่ฉันต้องยอมรับว่าโซลูชันนี้ใช้งานได้และอนุญาตให้มีการเปิดตัวที่เสถียร

วันที่ # -701: ห้องครัวที่เข้าใจได้และทดสอบ

การพัฒนาแนวคิดการทดสอบ Ansible คือการใช้เครื่องมือสำเร็จรูป ได้แก่ test kitchen / kitchen-ci และ inspec ตัวเลือกถูกกำหนดโดยความรู้เกี่ยวกับ Ruby (สำหรับรายละเอียดเพิ่มเติม ดูบทความเกี่ยวกับHabré: โปรแกรมเมอร์ YML ใฝ่ฝันที่จะทดสอบ Ansible หรือไม่?) ทำงานเร็วขึ้น ประมาณ 40 นาที สำหรับ 10 บทบาท เราสร้างชุดเครื่องเสมือนและทำการทดสอบภายใน

โดยทั่วไปแล้ว สารละลายได้ผล แต่มีตะกอนอยู่บ้างเนื่องจากความแตกต่างกัน เมื่อจำนวนคนที่ทดสอบเพิ่มขึ้นเป็น 13 บทบาทพื้นฐานและ 2 บทบาทเมตาที่รวมบทบาทที่เล็กลง การทดสอบก็เริ่มดำเนินไปเป็นเวลา 70 นาที ซึ่งนานกว่าเกือบ 2 เท่า เป็นเรื่องยากที่จะพูดถึงแนวทางปฏิบัติของ XP (Extreme Programming) เพราะ... ไม่มีใครอยากรอถึง 70 นาที นี่คือเหตุผลในการเปลี่ยนแนวทาง

วันที่ # -601: ตอบได้และเป็นโมเลกุล

ตามแนวคิดแล้ว สิ่งนี้จะคล้ายกับ testkitchen เพียงแต่เราย้ายการทดสอบบทบาทไปที่นักเทียบท่าและเปลี่ยนสแต็ก ส่งผลให้เวลาลดลงเหลือ 20-25 นาทีคงที่สำหรับ 7 บทบาท

ด้วยการเพิ่มจำนวนบทบาทที่ทดสอบเป็น 17 บทบาทและ Linting 45 บทบาท เราดำเนินการนี้ได้ภายใน 28 นาทีกับทาสเจนกินส์ 2 คน

วันที่ #167: การเพิ่มการทดสอบ Ansible ให้กับโปรเจ็กต์

เป็นไปได้มากว่าจะไม่สามารถดำเนินการปรับโครงสร้างใหม่อย่างเร่งด่วนได้ งานจะต้องวัดได้จึงจะแบ่งเป็นชิ้นเล็ก ๆ และกินช้างทีละชิ้นด้วยช้อนชา จะต้องมีความเข้าใจว่าคุณกำลังเดินไปถูกทางหรือไม่, จะต้องไปอีกนานแค่ไหน.

โดยทั่วไปแล้วไม่สำคัญว่าจะทำยังไง จะเขียนใส่กระดาษ ติดสติกเกอร์บนตู้เสื้อผ้า สร้างงานใน Jira หรือเปิด Google Docs แล้วจดสถานะปัจจุบันก็ได้ ที่นั่น. ขางอกจากการที่กระบวนการไม่ได้เกิดขึ้นทันทีมันจะยาวและน่าเบื่อ ไม่น่าจะมีใครอยากให้คุณหมดความคิด เหนื่อยล้า และรู้สึกหนักใจระหว่างการปรับโครงสร้างใหม่

การปรับโครงสร้างใหม่นั้นง่ายมาก:

กิน.
นอนหลับ
รหัส.
การทดสอบไอเอซี
ทำซ้ำ

และเราทำซ้ำจนกว่าเราจะบรรลุเป้าหมายที่ตั้งใจไว้

อาจเป็นไปไม่ได้ที่จะเริ่มทดสอบทุกอย่างทันที ดังนั้นงานแรกของเราคือเริ่มต้นด้วยการ Lint และตรวจสอบไวยากรณ์

วันที่ #181: ปรมาจารย์ Green Build

Linting ถือเป็นก้าวแรกเล็กๆ สู่ Green Build Master สิ่งนี้จะไม่เสียหายเกือบทุกอย่าง แต่จะช่วยให้คุณสามารถดีบักกระบวนการและสร้างบิลด์ที่เป็นมิตรต่อสิ่งแวดล้อมในเจนกินส์ได้ แนวคิดคือการพัฒนานิสัยระหว่างทีม:

การทดสอบสีแดงไม่ดี
ฉันมาเพื่อแก้ไขบางอย่างและในขณะเดียวกันก็ทำให้โค้ดดีขึ้นกว่าเดิมเล็กน้อย

วันที่ #193: จากขุยไปจนถึงการทดสอบหน่วย

เมื่อสร้างกระบวนการรับโค้ดลงในต้นแบบแล้ว คุณสามารถเริ่มกระบวนการปรับปรุงทีละขั้นตอนได้ โดยแทนที่ Linting ด้วยบทบาทการเปิดตัว คุณสามารถทำได้โดยไม่ต้องมีจุดเดิมเลย คุณต้องเข้าใจวิธีการใช้บทบาทและวิธีการทำงาน

วันที่ #211: จากหน่วยการเรียนรู้ไปจนถึงการทดสอบบูรณาการ

เมื่อบทบาทส่วนใหญ่ครอบคลุมด้วยการทดสอบหน่วยและทุกอย่างถูกเชื่อมโยงแล้ว คุณสามารถดำเนินการเพิ่มการทดสอบบูรณาการได้ เหล่านั้น. การทดสอบไม่ใช่อิฐก้อนเดียวในโครงสร้างพื้นฐาน แต่เป็นการทดสอบรวมกัน เช่น การกำหนดค่าอินสแตนซ์แบบเต็ม

ด้วยการใช้ jenkins เราได้สร้างขั้นตอนต่างๆ มากมายที่เชื่อมโยงบทบาท/คู่มือกลยุทธ์ไปพร้อมๆ กัน จากนั้นจึงทดสอบหน่วยในคอนเทนเนอร์ และสุดท้ายคือการทดสอบการบูรณาการ

เจนกินส์ + นักเทียบท่า + Ansible = การทดสอบ

ชำระเงิน repo และสร้างขั้นตอนการสร้าง
เรียกใช้ขั้นตอน Playbook Lint พร้อมกัน
ดำเนินขั้นตอนบทบาทของผ้าสำลีไปพร้อมๆ กัน
รันขั้นตอนบทบาทการตรวจสอบไวยากรณ์แบบขนาน
รันขั้นตอนบทบาทการทดสอบแบบขนาน
1. บทบาทผ้าสำลี
2. ตรวจสอบการพึ่งพาบทบาทอื่นๆ
3. ตรวจสอบไวยากรณ์
4. สร้างอินสแตนซ์นักเทียบท่า
5. เรียกใช้โมเลกุล/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: เร่งการทดสอบ

เมื่อเวลาผ่านไป มีการทดสอบมากขึ้น บิลด์ทำงานช้าลง โดยอาจถึงหนึ่งชั่วโมงในกรณีที่แย่ที่สุด ในยุคเรโทรช่วงหนึ่งมีวลีเช่น “ดีที่มีการทดสอบ แต่ก็ช้า” ด้วยเหตุนี้ เราจึงละทิ้งการทดสอบการรวมระบบบนเครื่องเสมือนและปรับให้เข้ากับ Docker เพื่อให้เร็วขึ้น นอกจากนี้เรายังแทนที่ testinfra ด้วย ansible verifier เพื่อลดจำนวนเครื่องมือที่ใช้

พูดอย่างเคร่งครัดมีชุดมาตรการ:

เปลี่ยนไปใช้นักเทียบท่า
ลบการทดสอบบทบาทซึ่งซ้ำกันเนื่องจากการขึ้นต่อกัน
เพิ่มจำนวนทาส
ทดสอบลำดับการทำงาน
ความสามารถในการขุย ทั้งหมด ภายในเครื่องด้วยคำสั่งเดียว

ผลก็คือ Pipeline on jenkins ก็เป็นอันหนึ่งอันเดียวกันเช่นกัน

สร้างขั้นตอนการสร้าง
ผ้าสำลีทั้งหมดขนานกัน
รันขั้นตอนบทบาทการทดสอบแบบขนาน
เสร็จสิ้น

บทเรียนที่ได้รับ

หลีกเลี่ยงตัวแปรร่วม

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

สิ่งที่ตลกก็คือผลลัพธ์ของ Playbook จะขึ้นอยู่กับสิ่งที่ไม่ชัดเจนเสมอไป เช่น ลำดับบทบาทที่แสดง น่าเสียดายที่นี่เป็นธรรมชาติของ Ansible และสิ่งที่ดีที่สุดที่สามารถทำได้คือการใช้ข้อตกลงบางประเภท เช่น ภายในบทบาท ให้ใช้เฉพาะตัวแปรที่อธิบายไว้ในบทบาทนี้

BAD: ใช้ตัวแปรโกลบอล

# 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

ตัวแปรบทบาทคำนำหน้า

BAD: ใช้ตัวแปรโกลบอล

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

ดี: ในบทบาทสำหรับตัวแปร ให้ใช้ตัวแปรนำหน้าด้วยชื่อบทบาท ซึ่งเมื่อดูที่รายการจะช่วยให้เข้าใจได้ง่ายขึ้นว่าเกิดอะไรขึ้น

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

ใช้ตัวแปรควบคุมลูป

BAD: ใช้ตัวแปรมาตรฐานในลูป 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

หลีกเลี่ยงพจนานุกรมแฮช ใช้โครงสร้างแบบแบน

หากบทบาทต้องการแฮช/พจนานุกรมในพารามิเตอร์ตัวใดตัวหนึ่ง ถ้าเราต้องการเปลี่ยนพารามิเตอร์ลูกตัวใดตัวหนึ่ง เราจะต้องแทนที่แฮช/พจนานุกรมทั้งหมด ซึ่งจะเพิ่มความซับซ้อนในการกำหนดค่า

BAD: ใช้แฮช/พจนานุกรม

---
user:
  name: admin
  group: admin

ดี: ใช้โครงสร้างตัวแปรแบบแบน

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

สร้าง Playbooks และบทบาทที่เป็นกลาง

บทบาทและ playbooks จะต้องเป็นแบบเดิมเพราะว่า ลดการเบี่ยงเบนของการกำหนดค่าและความกลัวที่จะทำลายบางสิ่ง แต่ถ้าคุณใช้โมเลกุล นี่เป็นพฤติกรรมเริ่มต้น

หลีกเลี่ยงการใช้โมดูลเชลล์คำสั่ง

การใช้โมดูลเชลล์ส่งผลให้เกิดกระบวนทัศน์คำอธิบายที่จำเป็น แทนที่จะเป็นแบบประกาศซึ่งเป็นแกนหลักของ 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 สนับสนุนแนวทางการประกาศ ดังนั้นเมื่อคุณทำการแตกสาขาโค้ด การแปลงข้อมูล โมดูลเชลล์ โค้ดจะอ่านได้ยาก เพื่อต่อสู้กับสิ่งนี้และทำให้มันง่ายต่อการเข้าใจ การต่อสู้กับความซับซ้อนนี้ด้วยการสร้างโมดูลของคุณเองนั้นไม่ใช่เรื่องฟุ่มเฟือย

สรุปเคล็ดลับและเทคนิค

หลีกเลี่ยงตัวแปรร่วม
ตัวแปรบทบาทคำนำหน้า
ใช้ตัวแปรควบคุมลูป
ตรวจสอบตัวแปรอินพุต
หลีกเลี่ยงพจนานุกรมแฮช ใช้โครงสร้างแบบแบน
สร้าง Playbooks และบทบาทที่เป็นกลาง
หลีกเลี่ยงการใช้โมดูลเชลล์คำสั่ง
ทดสอบบทบาทของคุณผ่านโมเลกุล
ใส่ตรรกะที่ซับซ้อนลงในโมดูลและปลั๊กอิน

ข้อสรุป

คุณไม่สามารถเปลี่ยนโครงสร้างโครงสร้างพื้นฐานในโปรเจ็กต์ได้ แม้ว่าคุณจะมี IaC ก็ตาม นี่เป็นกระบวนการที่ยาวนานซึ่งต้องใช้ความอดทน เวลา และความรู้

การเชื่อมโยง

อัพพีดี1 2020.05.01 20:30น — สำหรับการสร้างโปรไฟล์หลักของ Playbook คุณสามารถใช้ได้ callback_whitelist = profile_tasks เพื่อทำความเข้าใจว่าอะไรได้ผลมาเป็นเวลานาน แล้วเราก็ผ่านไปได้ การเร่งความเร็วแบบคลาสสิก. คุณยังสามารถลอง ไมโทเจน
อัพพีดี2 2020.05.03 16:34น - เวอร์ชันภาษาอังกฤษ

ที่มา: will.com

วิธีเริ่มการทดสอบ Ansible ปรับโครงสร้างโครงการใหม่ภายในหนึ่งปีและไม่บ้าไปกว่านี้