Bản phát hành sắp tới của Red Hat Ansible Engine 2.9 mang đến những cải tiến thú vị, một số cải tiến đó sẽ được thảo luận trong bài viết này. Như thường lệ, chúng tôi đang phát triển các cải tiến của Mạng Ansible một cách công khai với sự hỗ trợ của cộng đồng. Hãy tham gia cùng chúng tôi - hãy xem và nghiên cứu kế hoạch phát triển trên trang wiki cho .
Như chúng tôi đã thông báo gần đây, hiện bao gồm Ansible Tower, Ansible Engine và tất cả nội dung Mạng Ansible. Ngày nay, hầu hết các nền tảng mạng phổ biến đều được triển khai thông qua các mô-đun Ansible. Ví dụ:
- Arista EOS
- Cisco IOS
- Cisco iOS XR
- Hệ điều hành Cisco NX
- Juniper Junos
- VyOS
Để có danh sách đầy đủ các nền tảng được Red Hat hỗ trợ đầy đủ thông qua đăng ký Ansible Automation, .
Chúng ta đã học được gì
Trong bốn năm qua, chúng tôi đã học được rất nhiều điều về việc phát triển nền tảng tự động hóa mạng. Chúng tôi cũng đã học được rằng như các tạo phẩm nền tảng được người dùng cuối sử dụng trong sách và vai trò của Ansible. Và đây là những gì chúng tôi phát hiện ra:
- Các tổ chức đang tự động hóa các thiết bị không chỉ của một mà của nhiều nhà cung cấp.
- Tự động hóa không chỉ là một hiện tượng kỹ thuật mà còn là một hiện tượng văn hóa.
- Việc tự động hóa mạng trên quy mô lớn khó khăn hơn tưởng tượng do các nguyên tắc kiến trúc cơ bản của thiết kế tự động hóa.
Khi chúng tôi thảo luận về kế hoạch tăng trưởng dài hạn hơn một năm trước, các khách hàng doanh nghiệp của chúng tôi đã yêu cầu những điều sau:
- Việc thu thập thông tin cần phải được chuẩn hóa tốt hơn và phù hợp hơn với quy trình tự động hóa trên tất cả các thiết bị.
- Việc cập nhật cấu hình trên thiết bị cũng cần phải chuẩn hóa và nhất quán để các mô-đun Ansible xử lý được nửa sau của chu trình sau khi thu thập dữ kiện.
- Chúng tôi cần các phương pháp nghiêm ngặt và được hỗ trợ để chuyển đổi cấu hình thiết bị thành dữ liệu có cấu trúc. Trên cơ sở này, nguồn sự thật có thể được chuyển khỏi thiết bị mạng.
Cải tiến thực tế
Việc thu thập dữ kiện từ các thiết bị mạng bằng Ansible thường diễn ra một cách ngẫu nhiên. Các nền tảng dựa trên web có các mức độ khả năng thu thập thông tin khác nhau nhưng chúng có rất ít hoặc không có chức năng phân tích cú pháp và tiêu chuẩn hóa cách trình bày dữ liệu theo cặp khóa-giá trị. Đọc Ken Celenza về việc phân tích và chuẩn hóa dữ liệu thực tế có thể khó khăn và vất vả như thế nào.
Bạn có thể đã nhận thấy chúng tôi đang làm việc với vai trò Ansible Network Engine. Đương nhiên, sau 24K lượt tải xuống, vai trò Network Engine đã nhanh chóng trở thành một trong những vai trò Ansible phổ biến nhất trong Ansible Galaxy cho các kịch bản tự động hóa mạng. Trước khi chúng tôi chuyển phần lớn nội dung này sang Ansible 2.8 để chuẩn bị cho những gì cần thiết trong Ansible 2.9, vai trò Ansible này đã cung cấp bộ công cụ đầu tiên để giúp phân tích cú pháp lệnh, quản lý lệnh và thu thập dữ liệu cho các thiết bị mạng.
Nếu bạn biết cách sử dụng Network Engine thì đây là một cách rất hiệu quả để thu thập, phân tích và chuẩn hóa dữ liệu thực tế để sử dụng trong Ansible. Điểm bất lợi của vai trò này là bạn cần tạo cả đống trình phân tích cú pháp cho từng nền tảng và cho tất cả hoạt động mạng. Để hiểu mức độ khó khăn trong việc tạo, vận chuyển và duy trì các trình phân tích cú pháp, hãy xem từ những người ở Cisco.
Tóm lại, việc lấy dữ liệu từ các thiết bị và chuẩn hóa chúng thành các cặp khóa-giá trị là điều cần thiết cho quá trình tự động hóa trên quy mô lớn, nhưng khó đạt được điều này khi bạn có nhiều nhà cung cấp và nền tảng mạng.
Mỗi mô-đun dữ kiện mạng trong Ansible 2.9 giờ đây có thể phân tích cấu hình của thiết bị mạng và trả về dữ liệu có cấu trúc - mà không cần thêm thư viện, vai trò Ansible hoặc trình phân tích cú pháp tùy chỉnh.
Kể từ Ansible 2.9, mỗi khi mô-đun mạng cập nhật được phát hành, mô-đun thực tế sẽ được cải tiến để cung cấp dữ liệu về phần cấu hình này. Nghĩa là, quá trình phát triển các sự kiện và mô-đun hiện diễn ra với tốc độ như nhau và chúng sẽ luôn có cấu trúc dữ liệu chung.
Cấu hình tài nguyên trên thiết bị mạng có thể được truy xuất và chuyển đổi thành dữ liệu có cấu trúc theo hai cách. Theo cả hai cách, bạn có thể thu thập và chuyển đổi danh sách tài nguyên cụ thể bằng từ khóa mới gather_network_resources. Tên tài nguyên khớp với tên mô-đun, rất thuận tiện.
Trong khi thu thập sự thật:
Sử dụng từ khóa gather_facts bạn có thể truy xuất cấu hình thiết bị hiện tại ở đầu cẩm nang, sau đó sử dụng cấu hình đó trong toàn bộ cẩm nang. Chỉ định các tài nguyên riêng lẻ sẽ được lấy từ thiết bị.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueBạn có thể nhận thấy điều gì đó mới mẻ trong những ví dụ này, cụ thể là - gather_facts: true hiện có sẵn để thu thập thông tin gốc cho các thiết bị mạng.
Sử dụng trực tiếp mô-đun dữ kiện mạng:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlaybook trả về các thông tin thực tế sau đây về giao diện:
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1Lưu ý cách Ansible truy xuất cấu hình gốc từ thiết bị Arista và chuyển đổi nó thành dữ liệu có cấu trúc để sử dụng làm cặp khóa-giá trị tiêu chuẩn cho các tác vụ và hoạt động tiếp theo.
Các dữ kiện giao diện có thể được thêm vào các biến được lưu trữ trong Ansible và được sử dụng ngay lập tức hoặc sau này làm đầu vào cho mô-đun tài nguyên eos_interfaces mà không cần xử lý hoặc chuyển đổi bổ sung.
Mô-đun tài nguyên
Vì vậy, chúng tôi đã trích xuất các dữ kiện, chuẩn hóa dữ liệu, đưa chúng vào sơ đồ cấu trúc dữ liệu nội bộ được tiêu chuẩn hóa và nhận được nguồn sự thật có sẵn. Hoan hô! Tất nhiên, điều này thật tuyệt nhưng chúng ta vẫn cần bằng cách nào đó chuyển đổi các cặp khóa-giá trị về cấu hình cụ thể mà nền tảng thiết bị cụ thể mong đợi. Hiện tại, chúng tôi cần các mô-đun dành riêng cho nền tảng để đáp ứng các yêu cầu chuẩn hóa và thu thập dữ kiện mới này.
Mô-đun tài nguyên là gì? Bạn có thể coi các phần cấu hình của thiết bị là tài nguyên do thiết bị đó cung cấp. Các mô-đun tài nguyên mạng được cố ý giới hạn ở một tài nguyên duy nhất và có thể được xếp chồng lên nhau giống như các khối xây dựng để định cấu hình các dịch vụ mạng phức tạp. Kết quả là, các yêu cầu và đặc tả cho mô-đun tài nguyên được đơn giản hóa một cách tự nhiên vì mô-đun tài nguyên có thể đọc и cấu hình một dịch vụ mạng cụ thể trên một thiết bị mạng.
Để giải thích chức năng của mô-đun tài nguyên, chúng ta hãy xem sổ tay ví dụ hiển thị hoạt động bình thường bằng cách sử dụng mô-đun và thông tin tài nguyên mạng mới eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changedNhư bạn có thể thấy, dữ liệu được thu thập từ thiết bị sẽ được chuyển trực tiếp đến mô-đun tài nguyên tương ứng mà không cần chuyển đổi. Khi khởi chạy, playbook sẽ truy xuất các giá trị từ thiết bị và so sánh chúng với các giá trị dự kiến. Trong ví dụ này, các giá trị được trả về đúng như mong đợi (nghĩa là nó kiểm tra độ lệch cấu hình) và báo cáo xem cấu hình có thay đổi hay không.
Cách lý tưởng để phát hiện sự sai lệch cấu hình là lưu trữ dữ kiện trong các biến được lưu trữ của Ansible và sử dụng chúng theo định kỳ với mô-đun tài nguyên ở chế độ kiểm tra. Đây là một phương pháp đơn giản để xem liệu ai đó có thay đổi giá trị theo cách thủ công hay không. Trong hầu hết các trường hợp, tổ chức cho phép thay đổi và cấu hình theo cách thủ công, mặc dù nhiều thao tác được thực hiện thông qua Ansible Automation.
Các mô-đun tài nguyên mới khác với các mô-đun trước đó như thế nào?
Đối với một kỹ sư tự động hóa mạng, có 3 điểm khác biệt chính giữa các mô-đun tài nguyên trong Ansible 2.9 và các phiên bản trước.
1) Đối với một tài nguyên mạng nhất định (cũng có thể được coi là một phần cấu hình), các mô-đun và dữ kiện sẽ phát triển đồng thời trên tất cả các hệ điều hành mạng được hỗ trợ. Chúng tôi nghĩ rằng nếu Ansible hỗ trợ cấu hình tài nguyên trên một nền tảng mạng thì chúng tôi nên hỗ trợ nó ở mọi nơi. Điều này giúp đơn giản hóa việc sử dụng các mô-đun tài nguyên vì giờ đây kỹ sư tự động hóa mạng có thể định cấu hình tài nguyên (chẳng hạn như LLDP) trên tất cả các hệ điều hành mạng có các mô-đun gốc và được hỗ trợ.
2) Các mô-đun tài nguyên hiện bao gồm một giá trị trạng thái.
merged: cấu hình được hợp nhất với cấu hình được cung cấp (mặc định);replaced: Cấu hình tài nguyên sẽ được thay thế bằng cấu hình được cung cấp;overridden: Cấu hình tài nguyên sẽ được thay thế bằng cấu hình được cung cấp; các trường hợp tài nguyên không cần thiết sẽ bị xóa;deleted: Cấu hình tài nguyên sẽ bị xóa/khôi phục về mặc định.
3) Các mô-đun tài nguyên hiện bao gồm các giá trị trả về ổn định. Khi mô-đun tài nguyên mạng đã thực hiện (hoặc đề xuất) những thay đổi cần thiết cho thiết bị mạng, nó sẽ trả về các cặp khóa-giá trị tương tự cho playbook.
before: cấu hình trên thiết bị dưới dạng dữ liệu có cấu trúc trước tác vụ;after: nếu thiết bị đã thay đổi (hoặc có thể thay đổi nếu sử dụng chế độ kiểm tra), cấu hình kết quả sẽ được trả về dưới dạng dữ liệu có cấu trúc;commands: Bất kỳ lệnh cấu hình nào chạy trên thiết bị để đưa thiết bị về trạng thái mong muốn.
Vậy tất cả những điều này có ý nghĩa gì? Tại sao nó lại quan trọng?
Bài đăng này đề cập đến nhiều khái niệm phức tạp, nhưng chúng tôi hy vọng rằng cuối cùng bạn sẽ hiểu rõ hơn về những gì khách hàng doanh nghiệp đang yêu cầu trong việc thu thập thực tế, chuẩn hóa dữ liệu và cấu hình vòng lặp cho nền tảng tự động hóa. Nhưng tại sao họ cần những cải tiến này? Nhiều tổ chức hiện đang theo đuổi chuyển đổi kỹ thuật số để làm cho môi trường CNTT của họ trở nên linh hoạt và cạnh tranh hơn. Dù tốt hay xấu, nhiều kỹ sư mạng trở thành nhà phát triển mạng vì lợi ích cá nhân hoặc theo lệnh của ban quản lý.
Các tổ chức đang nhận ra rằng việc tự động hóa các mẫu mạng riêng lẻ không giải quyết được vấn đề về silo và chỉ tăng hiệu quả ở một mức độ nhất định. Nền tảng tự động hóa Ansible của Red Hat cung cấp các mô hình dữ liệu tài nguyên chuẩn mực và nghiêm ngặt để quản lý dữ liệu cơ bản trên thiết bị mạng theo chương trình. Nghĩa là, người dùng đang dần từ bỏ các phương pháp cấu hình riêng lẻ để chuyển sang các phương pháp hiện đại hơn, tập trung vào công nghệ (ví dụ: địa chỉ IP, Vlan, LLDP, v.v.), thay vì triển khai một nhà cung cấp cụ thể.
Phải chăng điều này có nghĩa là ngày của các mô-đun lệnh và cấu hình đáng tin cậy và đã được chứng minh đã sắp hết? Không có trường hợp nào. Các mô-đun tài nguyên mạng dự kiến sẽ không thể áp dụng được trong mọi trường hợp hoặc cho mọi nhà cung cấp, do đó, các kỹ sư mạng sẽ vẫn cần đến các mô-đun lệnh và cấu hình cho một số hoạt động triển khai nhất định. Mục đích của các mô-đun tài nguyên là đơn giản hóa các mẫu Jinja lớn và chuẩn hóa cấu hình thiết bị phi cấu trúc thành định dạng JSON có cấu trúc. Với các mô-đun tài nguyên, các mạng hiện có sẽ dễ dàng hơn trong việc chuyển đổi cấu hình của chúng thành các cặp khóa-giá trị có cấu trúc đại diện cho nguồn sự thật dễ đọc. Bằng cách sử dụng các cặp khóa-giá trị có cấu trúc, bạn có thể chuyển từ chạy cấu hình trên từng thiết bị sang làm việc với dữ liệu có cấu trúc độc lập và đưa mạng lên hàng đầu trong phương pháp tiếp cận cơ sở hạ tầng dưới dạng mã.
Những mô-đun tài nguyên nào sẽ có trong Ansible Engine 2.9?
Trước khi cho bạn biết chi tiết điều gì sẽ xảy ra trong Ansible 2.9, hãy nhớ lại cách chúng tôi phân chia toàn bộ phạm vi công việc.
Chúng tôi đã xác định 7 danh mục và chỉ định tài nguyên mạng cụ thể cho từng danh mục:
Lưu ý: Các tài nguyên in đậm đã được lên kế hoạch và triển khai trong Ansible 2.9.
Dựa trên phản hồi từ khách hàng doanh nghiệp và cộng đồng, việc giải quyết các mô-đun liên quan đến giao thức cấu trúc liên kết mạng, ảo hóa và giao diện trước tiên là điều hợp lý.
Các mô-đun tài nguyên sau được nhóm Ansible Network phát triển và tương ứng với các nền tảng được Red Hat hỗ trợ:
Các mô-đun sau được phát triển bởi cộng đồng Ansible:
exos_lldp_global- từ Extreme Networks.nxos_bfd_interfaces- từ Cisconxos_telemetry- từ Cisco
Như bạn có thể thấy, khái niệm mô-đun tài nguyên phù hợp với chiến lược lấy nền tảng làm trung tâm của chúng tôi. Nghĩa là, chúng tôi đưa các khả năng và chức năng cần thiết vào chính Ansible để hỗ trợ tiêu chuẩn hóa trong việc phát triển các mô-đun mạng, đồng thời để đơn giản hóa công việc của người dùng ở cấp độ vai trò và sách hướng dẫn Ansible. Để mở rộng việc phát triển các mô-đun tài nguyên, nhóm Ansible đã phát hành công cụ Trình tạo mô-đun.
Các kế hoạch cho Ansible 2.10 trở lên
Sau khi Ansible 2.9 được phát hành, chúng tôi sẽ nghiên cứu bộ mô-đun tài nguyên tiếp theo cho Ansible 2.10, có thể được sử dụng để định cấu hình thêm chính sách và cấu trúc liên kết mạng, ví dụ: . Kế hoạch phát triển vẫn có thể điều chỉnh nên nếu có ý kiến đóng góp vui lòng báo cáo .
Tài nguyên và bắt đầu
Nguồn: www.habr.com