Đây là bảng điểm trên :
Bắt đầu từ lần xác nhận thứ hai, bất kỳ mã nào cũng trở thành kế thừa, bởi vì những ý tưởng ban đầu bắt đầu khác xa với thực tế khắc nghiệt. Điều này không tốt cũng không xấu, nó là một điều khó tranh cãi và phải chấp nhận. Một phần của quá trình này là tái cấu trúc. Tái cấu trúc cơ sở hạ tầng dưới dạng mã. Hãy bắt đầu câu chuyện về cách tái cấu trúc Ansible trong một năm và không phát điên.
Sự ra đời của di sản
Ngày #1: Bệnh nhân số XNUMX
Ngày xửa ngày xưa có một dự án có điều kiện. Nó có một nhóm phát triển Dev và các kỹ sư Ops. Họ đang giải quyết cùng một vấn đề: cách triển khai máy chủ và chạy ứng dụng. Vấn đề là mỗi đội giải quyết vấn đề này theo cách riêng của mình. Tại dự án, người ta đã quyết định sử dụng Ansible để đồng bộ hóa kiến thức giữa nhóm Dev và Ops.
Ngày thứ 89: Sự ra đời của di sản
Bản thân họ không hề nhận ra điều đó, họ muốn làm điều đó tốt nhất có thể, nhưng hóa ra đó lại là di sản. Làm thế nào điều này xảy ra?
- Chúng ta có một nhiệm vụ khẩn cấp ở đây, hãy thực hiện một cú hack bẩn và sau đó sửa nó.
- Bạn không cần phải viết tài liệu và mọi thứ đều rõ ràng những gì đang diễn ra ở đây.
- Tôi biết Ansible/Python/Bash/Terraform! Nhìn xem tôi có thể né được thế nào đây!
- Tôi là Nhà phát triển Full Stack Overflow và đã sao chép điều này từ stackoverflow, tôi không biết nó hoạt động như thế nào, nhưng nó trông rất tuyệt và giải quyết được vấn đề.
Kết quả là, bạn có thể nhận được một loại mã khó hiểu mà không có tài liệu, không rõ nó làm gì, có cần thiết hay không, nhưng vấn đề là bạn cần phát triển nó, sửa đổi nó, thêm nạng và hỗ trợ , khiến tình hình càng trở nên tồi tệ hơn.
- hosts: localhost
tasks:
- shell: echo -n Z >> a.txt && cat a.txt
register: output
delay: 1
retries: 5
until: not output.stdout.find("ZZZ")Ngày #109: Nhận thức về vấn đề
Mô hình IaC được hình thành và triển khai ban đầu không còn đáp ứng được yêu cầu của người dùng/doanh nghiệp/các nhóm khác và thời gian thực hiện các thay đổi đối với cơ sở hạ tầng không còn có thể chấp nhận được. Tại thời điểm này, sự hiểu biết xuất hiện rằng đã đến lúc phải hành động.
Tái cấu trúc IaC
Ngày #139: Bạn có thực sự cần tái cấu trúc không?
Trước khi vội vàng tái cấu trúc, bạn phải trả lời một số câu hỏi quan trọng:
- Tại sao bạn cần tất cả điều này?
- Bạn có thời gian không?
- Kiến thức đã đủ chưa?
Nếu bạn không biết cách trả lời các câu hỏi thì quá trình tái cấu trúc sẽ kết thúc trước khi nó bắt đầu hoặc nó có thể trở nên tồi tệ hơn. Bởi vì đã có kinh nghiệm( ), sau đó dự án đã nhận được yêu cầu trợ giúp để khắc phục các vai trò và thực hiện chúng bằng các bài kiểm tra.
Ngày #149: Chuẩn bị tái cấu trúc
Việc đầu tiên là chuẩn bị. Quyết định những gì chúng tôi sẽ làm. Để làm được điều này, chúng tôi giao tiếp, tìm ra các vấn đề và tìm ra cách giải quyết chúng. Chúng tôi ghi lại các khái niệm thu được bằng cách nào đó, chẳng hạn như một bài viết hợp lưu, để khi đặt ra câu hỏi “cái gì là tốt nhất?” hoặc "cái nào đúng?" Chúng tôi không hề lạc đường. Trong trường hợp của chúng tôi, chúng tôi bám vào ý tưởng chia ra và cai trị: chúng tôi chia cơ sở hạ tầng thành từng mảnh/gạch nhỏ. Cách tiếp cận này cho phép bạn sử dụng một phần cơ sở hạ tầng biệt lập, hiểu chức năng của nó, thực hiện các thử nghiệm và thay đổi nó mà không sợ phá vỡ bất cứ điều gì.
Hóa ra thử nghiệm cơ sở hạ tầng trở thành nền tảng và ở đây điều đáng nói là kim tự tháp thử nghiệm cơ sở hạ tầng. Ý tưởng tương tự như đang được phát triển, nhưng dành cho cơ sở hạ tầng: chúng tôi đang chuyển từ các thử nghiệm nhanh rẻ tiền để kiểm tra những thứ đơn giản, chẳng hạn như thụt lề, sang các thử nghiệm chính thức đắt tiền triển khai toàn bộ cơ sở hạ tầng.
Các nỗ lực thử nghiệm Ansible
Trước khi mô tả cách chúng tôi thực hiện các thử nghiệm Ansible trong dự án, tôi sẽ mô tả những nỗ lực và cách tiếp cận mà tôi đã có cơ hội sử dụng trước đó để hiểu bối cảnh của các quyết định được đưa ra.
Ngày thứ -997: Cung cấp SDS
Lần đầu tiên tôi thử nghiệm Ansible là trong một dự án phát triển SDS (Bộ lưu trữ được xác định bằng phần mềm). Có một bài viết riêng về chủ đề này
, nhưng tóm lại, chúng tôi đã kết thúc bằng một kim tự tháp thử nghiệm đảo ngược và thử nghiệm chúng tôi dành 60-90 phút cho một vai trò, một khoảng thời gian dài. Cơ sở là các bài kiểm tra e2e, tức là. chúng tôi đã triển khai bản cài đặt chính thức và sau đó thử nghiệm nó. Điều thậm chí còn trầm trọng hơn là việc anh ta phát minh ra chiếc xe đạp của chính mình. Nhưng tôi phải thừa nhận, giải pháp này đã hiệu quả và cho phép phát hành ổn định.
Ngày # -701: Bếp Ansible và bếp thử nghiệm
Sự phát triển của ý tưởng thử nghiệm Ansible là việc sử dụng các công cụ làm sẵn, cụ thể là test Kitchen / Kitchen-ci và inspec. Sự lựa chọn được quyết định bởi kiến thức về Ruby (để biết thêm chi tiết, xem bài viết trên Habré: ) hoạt động nhanh hơn, khoảng 40 phút cho 10 vai trò. Chúng tôi đã tạo một gói máy ảo và chạy thử nghiệm bên trong.
Nhìn chung, giải pháp này có hiệu quả nhưng có một số cặn do tính không đồng nhất. Khi số lượng người thử nghiệm tăng lên 13 vai trò cơ bản và 2 vai trò meta kết hợp các vai trò nhỏ hơn, thì đột nhiên các thử nghiệm bắt đầu chạy trong 70 phút, dài hơn gần gấp 2 lần. Thật khó để nói về thực hành XP (lập trình cực đoan) bởi vì... không ai muốn đợi 70 phút. Đây là lý do phải thay đổi cách tiếp cận
Ngày # -601: Ansible và phân tử
Về mặt khái niệm, điều này tương tự như testkitchen, chỉ có điều chúng tôi đã chuyển thử nghiệm vai trò sang docker và thay đổi ngăn xếp. Kết quả là thời gian được giảm xuống ổn định ở mức 20-25 phút cho 7 vai.
Bằng cách tăng số lượng vai trò được thử nghiệm lên 17 và xác định 45 vai trò, chúng tôi đã thực hiện việc này trong 28 phút trên 2 nô lệ của Jenkins.
Ngày #167: Thêm thử nghiệm Ansible vào dự án
Rất có thể, bạn sẽ không thể thực hiện nhiệm vụ tái cấu trúc một cách vội vàng. Nhiệm vụ phải đo lường được để bạn có thể chia nó thành từng miếng nhỏ và dùng thìa cà phê ăn từng miếng con voi. Phải có sự hiểu biết xem mình có đang đi đúng hướng hay không, đi được bao lâu.
Nói chung, việc thực hiện như thế nào không quan trọng, bạn có thể viết lên một tờ giấy, bạn có thể dán nhãn dán lên tủ, bạn có thể tạo nhiệm vụ trong Jira hoặc bạn có thể mở Google Docs và viết ra trạng thái hiện tại ở đó. Đôi chân phát triển do quá trình này không diễn ra ngay lập tức mà sẽ kéo dài và tẻ nhạt. Chắc chắn không ai muốn bạn cạn kiệt ý tưởng, mệt mỏi và choáng ngợp trong quá trình tái cấu trúc.
Việc tái cấu trúc rất đơn giản:
- Ăn.
- Ngủ.
- Mã.
- Kiểm tra IaC.
- Lặp lại
và chúng tôi lặp lại điều này cho đến khi đạt được mục tiêu đã định.
Có thể không thể bắt đầu thử nghiệm mọi thứ ngay lập tức, vì vậy nhiệm vụ đầu tiên của chúng tôi là bắt đầu với việc tìm lỗi mã nguồn và kiểm tra cú pháp.
Ngày #181: Bậc thầy xây dựng xanh
Linting là bước nhỏ đầu tiên hướng tới Green Build Master. Điều này sẽ không phá vỡ hầu hết mọi thứ nhưng nó sẽ cho phép bạn gỡ lỗi các quy trình và tạo các bản dựng xanh trong Jenkins. Ý tưởng là phát triển thói quen trong nhóm:
- Kiểm tra màu đỏ là xấu.
- Tôi đến để sửa một số thứ và đồng thời làm cho mã tốt hơn một chút so với trước đây của bạn.
Ngày #193: Từ linting đến unit test
Sau khi xây dựng quy trình đưa mã vào bản gốc, bạn có thể bắt đầu quá trình cải tiến từng bước - thay thế linting bằng các vai trò khởi chạy, bạn thậm chí có thể thực hiện điều đó mà không cần bất kỳ sự thay đổi nào. Bạn cần hiểu cách áp dụng các vai trò và cách chúng hoạt động.
Ngày #211: Từ bài kiểm tra đơn vị đến bài kiểm tra tích hợp
Khi hầu hết các vai trò đều được thực hiện bằng các bài kiểm tra đơn vị và mọi thứ đều được xác định rõ ràng, bạn có thể chuyển sang thêm các bài kiểm tra tích hợp. Những thứ kia. thử nghiệm không phải một khối duy nhất trong cơ sở hạ tầng mà là sự kết hợp của chúng, chẳng hạn như cấu hình phiên bản đầy đủ.
Bằng cách sử dụng jenkins, chúng tôi đã tạo ra nhiều giai đoạn sắp xếp song song các vai trò/sách chơi, sau đó kiểm thử đơn vị trong vùng chứa và cuối cùng là kiểm thử tích hợp.
Jenkins + Docker + Ansible = Kiểm tra
- Kiểm tra repo và tạo các giai đoạn xây dựng.
- Chạy song song các giai đoạn của sách tìm lỗi mã nguồn.
- Chạy song song các giai đoạn vai trò tìm lỗi mã nguồn.
- Chạy song song các giai đoạn vai trò kiểm tra cú pháp.
- Chạy song song các giai đoạn vai trò thử nghiệm.
- Vai trò Lint.
- Kiểm tra sự phụ thuộc vào các vai trò khác.
- Kiểm tra cú pháp.
- Tạo phiên bản docker
- Chạy phân tử/mặc định/playbook.yml.
- Kiểm tra tính bình thường.
- Chạy thử nghiệm tích hợp
- Kết thúc
Ngày #271: Yếu tố xe buýt
Lúc đầu, việc tái cấu trúc được thực hiện bởi một nhóm nhỏ gồm hai hoặc ba người. Họ đã xem lại mã trong bản gốc. Theo thời gian, nhóm đã phát triển kiến thức về cách viết mã và việc đánh giá mã đã góp phần phổ biến kiến thức về cơ sở hạ tầng và cách thức hoạt động của nó. Điểm nổi bật ở đây là những người đánh giá được chọn từng người một, theo một lịch trình, tức là. với một mức độ xác suất nào đó, bạn sẽ leo lên một phần cơ sở hạ tầng mới.
Và ở đây chắc phải thoải mái lắm. Thật thuận tiện để đánh giá, xem trong khuôn khổ nhiệm vụ đã thực hiện và lịch sử các cuộc thảo luận. Chúng tôi đã tích hợp jenkins + bitbucket + jira.
Nhưng như vậy, đánh giá không phải là thuốc chữa bách bệnh; bằng cách nào đó, chúng tôi đã xâm nhập vào mã chính, khiến chúng tôi thất bại trong các bài kiểm tra:
- 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 }}"Sau đó họ sửa lại nhưng cặn vẫn còn.
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 }}"Ngày #311: Tăng tốc kiểm tra
Theo thời gian, có nhiều thử nghiệm hơn, các bản dựng chạy chậm hơn, trong trường hợp xấu nhất có thể lên đến một giờ. Trên một trong những bản retro có một cụm từ như "thật tốt khi có các bài kiểm tra, nhưng chúng chậm". Do đó, chúng tôi đã bỏ các thử nghiệm tích hợp trên máy ảo và điều chỉnh chúng cho Docker để làm cho nó nhanh hơn. Chúng tôi cũng thay thế testinfra bằng trình xác minh ansible để giảm số lượng công cụ được sử dụng.
Nói đúng ra, có một loạt các biện pháp:
- Chuyển sang docker.
- Loại bỏ kiểm tra vai trò bị trùng lặp do phụ thuộc.
- Tăng số lượng nô lệ.
- Thứ tự chạy thử.
- Khả năng xơ vải TẤT CẢ CÁC cục bộ bằng một lệnh.
Kết quả là Pipeline trên jenkins cũng được hợp nhất
- Tạo các giai đoạn xây dựng.
- Lint tất cả song song.
- Chạy song song các giai đoạn vai trò thử nghiệm.
- Kết thúc.
Bài học kinh nghiệm
Tránh các biến toàn cục
Ansible sử dụng các biến toàn cục, có một cách giải quyết một phần ở dạng , nhưng đây không phải là thuốc chữa bách bệnh.
Tôi sẽ cho bạn một ví dụ. Hãy để chúng tôi có 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}}
Điều buồn cười là kết quả của các vở kịch sẽ phụ thuộc vào những thứ không phải lúc nào cũng rõ ràng, chẳng hạn như thứ tự liệt kê các vai trò. Thật không may, đây là bản chất của Ansible và điều tốt nhất có thể làm là sử dụng một số loại thỏa thuận, ví dụ: trong một vai trò, chỉ sử dụng biến được mô tả trong vai trò này.
BAD: sử dụng biến toàn cục.
# cat roles/some_role/tasks/main.yml
---
debug:
var: java_homeTỐT: V defaults xác định các biến cần thiết và sau đó chỉ sử dụng chúng.
# 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
Biến vai trò tiền tố
BAD: sử dụng biến toàn cục.
# cat roles/some_role/defaults/main.yml
---
db_port: 5432TỐT: Trong vai trò dành cho biến, hãy sử dụng biến có tiền tố là tên vai trò; điều này, bằng cách xem kho lưu trữ, sẽ giúp bạn dễ hiểu điều gì đang xảy ra hơn.
# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432Sử dụng biến điều khiển vòng lặp
BAD: Sử dụng biến tiêu chuẩn trong vòng lặp item, nếu nhiệm vụ/cẩm nang này được đưa vào đâu đó, điều này có thể dẫn đến hành vi không mong muốn
---
- hosts: localhost
tasks:
- debug:
msg: "{{ item }}"
loop:
- item1
- item2
TỐT: Xác định lại một biến trong một vòng lặp thông qua loop_var.
---
- hosts: localhost
tasks:
- debug:
msg: "{{ item_name }}"
loop:
- item1
- item2
loop_control:
loop_var: item_name
Kiểm tra các biến đầu vào
Chúng tôi đã đồng ý sử dụng các tiền tố có thể thay đổi; sẽ không thừa khi kiểm tra xem chúng có được xác định như chúng tôi mong đợi hay không và, chẳng hạn, không bị ghi đè bởi một giá trị trống
TỐT: Kiểm tra các biến.
- 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_item3Tránh từ điển băm, sử dụng cấu trúc phẳng
Nếu một vai trò yêu cầu hàm băm/từ điển ở một trong các tham số của nó thì nếu muốn thay đổi một trong các tham số con, chúng ta sẽ cần ghi đè toàn bộ hàm băm/từ điển, điều này sẽ làm tăng độ phức tạp của cấu hình.
BAD: Sử dụng hàm băm/từ điển.
---
user:
name: admin
group: adminTỐT: Sử dụng cấu trúc biến phẳng.
---
user_name: admin
user_group: "{{ user_name }}"Tạo các vở kịch và vai trò bình thường
Các vai trò và sách chơi phải bình đẳng, bởi vì giảm sự trôi dạt cấu hình và sợ phá vỡ thứ gì đó. Nhưng nếu bạn sử dụng phân tử thì đây là hành vi mặc định.
Tránh sử dụng các mô-đun shell lệnh
Việc sử dụng mô-đun shell dẫn đến mô hình mô tả mệnh lệnh, thay vì mô hình khai báo, vốn là cốt lõi của Ansible.
Kiểm tra vai trò của bạn thông qua phân tử
Phân tử là một thứ rất linh hoạt, chúng ta hãy xem xét một vài tình huống.
Phân tử Nhiều trường hợp
В molecule.yml trong phần platforms bạn có thể mô tả nhiều máy chủ mà bạn có thể triển khai.
---
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: hostTheo đó, những máy chủ này sau đó có thể được converge.yml sử dụng:
---
- 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_roleTrình xác minh ansible
Trong phân tử, có thể sử dụng ansible để kiểm tra xem phiên bản đã được cấu hình đúng chưa, hơn nữa, đây là mặc định kể từ bản phát hành 3. Nó không linh hoạt như testinfra/inspec, nhưng chúng ta có thể kiểm tra xem nội dung của tệp có khớp với mong đợi của chúng ta hay không:
---
- 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.changedHoặc triển khai dịch vụ, đợi dịch vụ sẵn sàng và thực hiện kiểm tra khói:
---
- 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Đưa logic phức tạp vào mô-đun và plugin
Ansible ủng hộ cách tiếp cận khai báo, vì vậy khi bạn thực hiện phân nhánh mã, chuyển đổi dữ liệu, mô-đun shell, mã sẽ trở nên khó đọc. Để giải quyết vấn đề này và giữ cho nó dễ hiểu, sẽ không thừa nếu bạn giải quyết sự phức tạp này bằng cách tạo các mô-đun của riêng bạn.
Tóm tắt mẹo & thủ thuật
- Tránh các biến toàn cục.
- Các biến vai trò tiền tố.
- Sử dụng biến điều khiển vòng lặp.
- Kiểm tra các biến đầu vào
- Tránh từ điển băm, sử dụng cấu trúc phẳng.
- Tạo các vở kịch và vai trò bình thường.
- Tránh sử dụng các mô-đun shell lệnh.
- Kiểm tra vai trò của bạn thông qua phân tử.
- Đưa logic phức tạp vào các mô-đun và plugin.
Kết luận
Bạn không thể cứ thế tái cấu trúc cơ sở hạ tầng của một dự án, ngay cả khi bạn có IaC. Đây là một quá trình lâu dài đòi hỏi sự kiên nhẫn, thời gian và kiến thức.
Liên kết
- Slides
- Video
CẬP NHẬT1 2020.05.01 20:30 — Để lập hồ sơ chính cho các sách giải trí, bạn có thể sử dụng callback_whitelist = profile_tasks để hiểu chính xác những gì hoạt động trong một thời gian dài. Sau đó chúng ta đi qua . Bạn cũng có thể thử
CẬP NHẬT2 2020.05.03 16:34 -
Nguồn: www.habr.com