Tìm hiểu về Ansible, Puppet, Chef -

Tìm hiểu về Ansible, Puppet, Chef

Đến bây giờ, bạn có nhìn thấy cách sử dụng IOS CLI để cấu hình Router và Switch. Để cấu hình bằng CLI, bạn vào chế độ cấu hình, đưa ra các lệnh cấu hình (thay đổi tệp cấu hình đang chạy) và cuối cùng rời khỏi chế độ cấu hình. Nếu bạn quyết định giữ những thay đổi đó, bạn lưu cấu hình vào tệp startup-config bằng lệnh copy running-config startup-config. Lần tới khi Router hoặc chuyển đổi khởi động, Router sẽ tải tập tin khởi động vào RAM dưới dạng cấu hình đang chạy.

Chương này thảo luận về các công cụ để quản lý cấu hình thay thế cho quá trình cấu hình trên mỗi thiết bị. Thậm chí để tưởng tượng những gì các công cụ này có thể làm, trước tiên đòi hỏi bạn phải có một bước nhảy vọt trong công việc hàng ngày của một kỹ sư mạng tại một doanh nghiệp vừa và lớn. Trong một hệ thống mạng thật, việc quản lý cấu hình của nhiều thiết bị mạng tạo ra những thách thức. Những thách thức đó có thể được giải quyết bằng cách sử dụng cùng một chế độ cấu hình cũ trên mỗi quy trình của thiết bị, cộng với làm việc chăm chỉ, chú ý đến chi tiết và thực hành vận hành tốt. Tuy nhiên, quá trình trên mỗi thiết bị thủ công đó ngày càng trở nên khó khăn hơn vì nhiều lý do, vì vậy, tại một số điểm, các doanh nghiệp chuyển sang các công cụ quản lý cấu hình tự động để cung cấp kết quả tốt hơn.

Phần đầu tiên của chương này có cái nhìn tổng quát về các vấn đề quản lý quy mô cấu hình cùng với một số giải pháp cho những vấn đề đó. Sau đó, phần chính thứ hai sẽ trình bày chi tiết về ba công cụ quản lý cấu hình -Ansible, Puppet và Chef- để xác định một số tính năng và thuật ngữ được sử dụng với mỗi công cụ. Đến cuối chương, bạn sẽ có thể thấy một số lý do tại sao các công cụ quản lý cấu hình tự động này có vai trò trong các mạng hiện đại và đủ ngữ cảnh để hiểu khi bạn chọn một để tìm hiểu thêm.

 

 

NHỮNG KHÓ KHĂN KHI CẤU HÌNH THIẾT BỊ VÀ GIẢI PHÁP CHO VẤN ĐỀ

Điều gì xác định cấu hình dự định chính xác của từng thiết bị trong mạng? Đây có phải là cấu hình đang chạy như hiện tại hay là cấu hình khởi động trước khi có bất kỳ thay đổi nào gần đây được thực hiện hoặc cấu hình khởi động từ tháng trước không? Một kỹ sư có thể thay đổi cấu hình thiết bị, với những nhân viên còn lại không biết? Quá trình nào, nếu có, có thể phát hiện ra sự thay đổi và khác biệt trong cấu hình? Và ngay cả với những thay đổi đã được tất cả đồng ý, làm thế nào để bạn biết ai đã thay đổi cấu hình, khi nào và cụ thể điều gì đã thay đổi?

Theo truyền thống, CCNA dạy chúng ta cách định cấu hình một thiết bị bằng lệnh configure terminal để đến chế độ cấu hình, thay đổi file cấu hình đang chạy và cách lưu cấu hình đang chạy vào file cấu hình khởi động. Quá trình thủ công đó không cung cấp phương tiện để trả lời bất kỳ câu hỏi nào được đặt ra bên trên; tuy nhiên, đối với nhiều doanh nghiệp, những câu hỏi đó (và những câu hỏi khác) cần câu trả lời, một cách nhất quán và chính xác.

Không phải mọi công ty đều đạt đến quy mô muốn làm điều gì đó nhiều hơn với quản lý cấu hình. Các công ty có một kỹ sư mạng có thể quản lý tốt cấu hình thiết bị, đặc biệt nếu cấu hình thiết bị mạng không thay đổi thường xuyên. Tuy nhiên, khi một team có nhiều kỹ sư mạng và phát triển số lượng thiết bị và loại thiết bị, với tốc độ thay đổi cấu hình cao hơn, quản lý cấu hình thủ công theo truyền thống bắt đầu phát sinh nhiều vấn đề.

 

Thay đổi cấu hình thiết bị

Hãy xem xét câu chuyện về một doanh nghiệp có quy mô cần hai kỹ sư mạng, Alice và Bob. Cả hai đều có kinh nghiệm và làm việc tốt với nhau. Nhưng cấu hình mạng đã phát triển vượt xa những gì bất kỳ ai có thể biết và với hai kỹ sư mạng, họ có thể nhớ các chi tiết khác nhau hoặc thậm chí đôi khi không đồng ý với nhau.

Ví dụ, một đêm lúc 1 giờ sáng, Bob nhận được một cuộc gọi về một vấn đề của hệ thống. Anh ta truy cập vào mạng từ máy tính xách tay của mình và giải quyết vấn đề bằng một thay đổi cấu hình nhỏ của Router văn phòng chi nhánh BR22. Alice, kỹ sư cao cấp khác, nhận được một cuộc gọi 4 giờ sáng khác về một vấn đề khác và thực hiện thay đổi cho Router văn phòng chi nhánh BR33.

Ngày hôm sau trở nên bận rộn với cả hai. Cả Alice và Bob đều không đề cập đến những thay đổi mà họ đã thực hiện. Cả hai đều tuân theo các quy trình và ghi lại các thay đổi trong hệ thống quản lý thay đổi của mình, trong đó liệt kê chi tiết của mọi thay đổi. Nhưng cả hai đều bận rộn, chủ đề về sự thay đổi cấu hình không bao giờ xuất hiện và không đề cập đến những thay đổi trong từng tháng.

Câu chuyện cho thấy sự thay đổi cấu hình có thể xảy ra như thế nào, một hiệu ứng trong đó cấu hình của hệ thống đã thay đổi theo thời gian. Alice và Bob có thể đồng ý với cấu hình của router văn phòng chi nhánh phải trông như thế nào, nhưng cả hai đều tạo ra ngoại lệ cho cấu hình đó để khắc phục sự cố, gây ra lỗi cấu hình. Hình 19-1 cho thấy ý tưởng cơ bản, với hai Router nhánh đó với cấu hình hơi khác so với các Router nhánh khác.

Hình 19-1 Cấu hình trôi dạt trong Router nhánh BR22 và BR33

 

Khác biệt cấu hình nêu trên trở thành một vấn đề lớn hơn nhiều nếu chỉ sử dụng các công cụ cấu hình thủ công truyền thống. Ví dụ:

●       Quá trình cấu hình thủ công trên thiết bị không theo dõi lịch sử của các thay đổi: dòng nào thay đổi, dòng nào thay đổi trên từng dòng, cấu hình cũ bị xóa, ai thay đổi cấu hình, khi mỗi thay đổi được thực hiện.

●       Các hệ thống bên ngoài được sử dụng bởi các quy trình quản lý hệ thống tốt, như ticket management system và phần mềm quản lý thay đổi, có thể ghi lại chi tiết. Tuy nhiên, những người ngồi ngoài cấu hình và yêu cầu phân tích để tìm ra những gì đã thay đổi. Họ cũng dựa vào con người để tuân theo các quy trình hoạt động một cách nhất quán và chính xác; mặt khác, một kỹ sư không thể tìm thấy toàn bộ lịch sử thay đổi cấu hình.

●       Đề cập đến dữ liệu lịch sử trong các hệ thống quản lý thay đổi hoạt động kém nếu một thiết bị đã trải qua nhiều thay đổi cấu hình trong một khoảng thời gian.

 

Tập tin cấu hình tập trung và kiểm soát phiên bản

 

Mô hình cấu hình thủ công trên mỗi thiết bị có ý nghĩa lớn đối với một người quản lý một thiết bị. Với mô hình đó, một kỹ sư mạng có thể sử dụng cấu hình khởi động trên thiết bị làm cấu hình lý tưởng dự định. Nếu cần thay đổi, kỹ sư sẽ vào chế độ cấu hình và cập nhật cấu hình đang chạy cho đến khi hài lòng với thay đổi. Sau đó, kỹ sư lưu một bản sao để khởi động cấu hình làm cấu hình lý tưởng hiện tại cho thiết bị.

Mô hình cấu hình thủ công trên mỗi thiết bị không hoạt động tốt đối với các mạng lớn hơn, với hàng trăm hoặc thậm chí hàng nghìn thiết bị mạng, với nhiều kỹ sư mạng. Chẳng hạn, nếu nhóm nghĩ rằng cấu hình khởi động của mỗi thiết bị là cấu hình lý tưởng, nếu một thành viên trong nhóm thay đổi cấu hình (như Alice và Bob từng làm trong câu chuyện trước đó), không có hồ sơ nào về sự thay đổi. Tệp cấu hình không hiển thị những gì đã thay đổi, khi thay đổi hoặc ai đã thay đổi và quy trình không thông báo cho toàn bộ nhóm về thay đổi.

Là bước đầu tiên để quản lý cấu hình tốt hơn, nhiều doanh nghiệp vừa và lớn lưu trữ cấu hình ở một vị trí trung tâm. Lúc đầu, việc lưu trữ tập trung có thể là một nỗ lực đơn giản để giữ các bản sao dự phòng của từng cấu hình trên thiết bị. Tất nhiên, họ sẽ đặt các tệp trong một thư mục dùng chung có thể truy cập được cho toàn bộ nhóm mạng, như trong Hình 19-2.

Hình 19-2 Sao chép cấu hình thiết bị vào một vị trí trung tâm

Tập tin cấu hình nào là nguồn duy nhất của sự thật trong mô hình này? Các tệp cấu hình vẫn tồn tại trên mỗi thiết bị, nhưng giờ đây chúng cũng tồn tại trên một máy chủ tập trung và các kỹ sư có thể thay đổi cấu hình trên thiết bị cũng như các tệp văn bản trên máy chủ. Chẳng hạn, nếu bản sao cấu hình BR21, trên thiết bị khác với tệp trên máy chủ tập trung, cần được coi là chính xác, lý tưởng, sự thật về những gì nhóm dự định cho thiết bị này?

Trong thực tế, các công ty có cả hai cách tiếp cận. Trong một số trường hợp, các công ty tiếp tục sử dụng các tệp cấu hình trên thiết bị làm nguồn sự thật, với các tệp cấu hình tập trung được coi là bản sao lưu trong trường hợp thiết bị bị lỗi và phải được thay thế. Tuy nhiên, các doanh nghiệp khác thực hiện chuyển đổi để coi các tệp trên máy chủ là nguồn sự thật duy nhất về mỗi tệp cấu hình thiết bị. Khi sử dụng tệp tập trung làm nguồn sự thật, các kỹ sư có thể tận dụng nhiều công cụ quản lý cấu hình và thực sự quản lý các cấu hình dễ dàng hơn và với độ chính xác cao hơn.

Ví dụ: các công cụ quản lý cấu hình sử dụng phần mềm kiểm soát phiên bản để theo dõi các thay đổi đối với các tệp cấu hình tập trung, lưu ý ai thay đổi tệp, dòng nào và ký tự cụ thể đã thay đổi, khi thay đổi xảy ra, v.v. Các công cụ cũng cho phép bạn so sánh sự khác biệt giữa các phiên bản của các tệp theo thời gian, như trong Hình 19-3.

 

Hình 19-3 Hiển thị sự khác biệt về tệp trong GitHub

Hình hiển thị một mẫu so sánh giữa hai phiên bản của tệp cấu hình. Hai dòng được tô sáng phía trên, với các dấu trừ, hiển thị các dòng được thay đổi, trong khi hai dòng được tô sáng thấp hơn, với các dấu cộng, hiển thị các phiên bản mới của mỗi dòng.

Phần mềm kiểm soát phiên bản giải quyết nhiều vấn đề với việc thiếu theo dõi thay đổi trong chính các thiết bị. Hình 19-3 cho thấy đầu ra từ một trang web dịch vụ phần mềm phổ biến có tên là GitHub (www.github.com). GitHub cung cấp các tài khoản miễn phí và trả phí và nó sử dụng phần mềm nguồn mở (Git) để thực hiện các chức năng kiểm soát phiên bản.

Giám sát cấu hình và thực thi

Với hệ thống kiểm soát phiên bản và quy ước lưu trữ các tệp cấu hình ở vị trí trung tâm, nhóm mạng có thể thực hiện công việc theo dõi các thay đổi và trả lời ai, cái gì và khi nào thay đổi trong mọi cấu hình trên thiết bị. Tuy nhiên, sử dụng mô hình đó sau đó giới thiệu các thách thức khác. Các thách thức có thể giải quyết tốt nhất bằng cách sử dụng công cụ quản lý cấu hình tự động.

Với mô hình mới này, các kỹ sư nên thực hiện thay đổi bằng cách chỉnh sửa các tệp cấu hình liên quan trong kho lưu trữ tập trung. Công cụ quản lý cấu hình sau đó có thể được chuyển hướng để sao chép hoặc áp dụng cấu hình cho thiết bị, như trong Hình 19-4. Sau khi quá trình đó hoàn tất, tập tin cấu hình trung tâm và thiết bị chạy running-config (và startup-config) sẽ giống hệt nhau.

Hình 19-4 Đẩy cấu hình tập trung vào thiết bị từ xa

Sử dụng mô hình hiển thị trong Hình 19-4 vẫn có những nguy hiểm. Chẳng hạn, các kỹ sư mạng nên thực hiện thay đổi bằng cách sử dụng các công cụ quản lý cấu hình, nhưng họ vẫn có khả năng đăng nhập vào từng thiết bị và thực hiện thay đổi thủ công trên từng thiết bị. Vì vậy, trong khi ý tưởng sử dụng một công cụ quản lý cấu hình với kho lưu trữ tập tin cấu hình tập trung nghe có vẻ hấp dẫn, cuối cùng sẽ có người thay đổi trực tiếp các thiết bị. Những thay đổi cấu hình chính xác trước đây có thể được ghi đè và thực hiện không chính xác bởi những thay đổi trong tương lai. Nói cách khác, cuối cùng, một số khác biệt trong cấu hình có thể xảy ra.

Các công cụ quản lý cấu hình có thể giám sát các cấu hình thiết bị để khám phá khi cấu hình thiết bị khác với cấu hình lý tưởng dự định và sau đó cấu hình lại thiết bị hoặc thông báo cho nhân viên kỹ thuật mạng để thực hiện thay đổi. Tính năng này có thể được gọi là giám sát cấu hình hoặc thực thi cấu hình, đặc biệt nếu công cụ tự động thay đổi cấu hình thiết bị.

Hình 19-5 cho thấy ý tưởng chung đằng sau giám sát cấu hình. Phần mềm quản lý cấu hình tự động yêu cầu một bản sao của tệp cấu hình đang chạy của thiết bị, như được hiển thị trong bước 1 và 2. Ở bước 3, phần mềm quản lý cấu hình so sánh tệp cấu hình lý tưởng với tệp cấu hình đang chạy để kiểm tra xem họ có bất kỳ sự khác biệt (trôi cấu hình). Theo cấu hình của công cụ, nó sẽ sửa cấu hình hoặc thông báo cho nhân viên về sự khác biệt trong cấu hình.

Hình 19-5 Giám sát cấu hình

Cung cấp cấu hình

Cung cấp cấu hình đề cập đến cách thức cung cấp hoặc triển khai các thay đổi đối với cấu hình được thực hiện bằng cách thay đổi các tệp trong hệ thống quản lý cấu hình. Là một trong những chức năng chính của công cụ quản lý cấu hình, bạn có thể sẽ thấy các tính năng như sau:

●       Chức năng cốt lõi để thực hiện thay đổi cấu hình trong một thiết bị sau khi ai đó đã chỉnh sửa tệp cấu hình tập trung của thiết bị

●       Khả năng chọn tập hợp con của thiết bị để định cấu hình: tất cả các thiết bị, loại có thuộc tính đã cho (chẳng hạn như thuộc tính cụ thể) hoặc chỉ một thiết bị, dựa trên thuộc tính và logic

●       Khả năng xác định xem mỗi thay đổi đã được chấp nhận hay từ chối và sử dụng logic để phản ứng khác nhau trong từng trường hợp tùy thuộc vào kết quả

●       Đối với mỗi thay đổi, khả năng hoàn nguyên về cấu hình ban đầu nếu thậm chí một lệnh cấu hình bị từ chối trên thiết bị

●       Khả năng xác thực thay đổi ngay bây giờ (mà không thực sự thực hiện thay đổi) để xác định xem thay đổi có hoạt động hay không khi thử

●       Khả năng kiểm tra cấu hình sau khi quá trình hoàn tất để xác nhận rằng công cụ quản lý cấu hình cấu hình dự định phù hợp với cấu hình của thiết bị.

●       Khả năng sử dụng logic để chọn có lưu cấu hình đang chạy vào cấu hình khởi động hay không

●       Khả năng biểu diễn các tệp cấu hình dưới dạng mẫu và biến để các thiết bị có vai trò tương tự có thể sử dụng cùng một mẫu nhưng với các giá trị khác nhau

●       Khả năng lưu trữ các bước logic trong một tệp, được lên lịch để thực hiện, để các thay đổi có thể được thực hiện bởi công cụ tự động hóa mà không có kỹ sư có mặt

Danh sách có thể bổ sung thêm nữa, nhưng các tính năng này phác thảo một số tính năng chính có trong tất cả các công cụ quản lý cấu hình được thảo luận trong chương này. Hầu hết các mục trong danh sách đều xoay quanh việc chỉnh sửa tệp cấu hình trung tâm cho thiết bị. Tuy nhiên, các công cụ có nhiều tính năng hơn, vì vậy bạn có nhiều việc phải làm để lập kế hoạch và thực hiện cách chúng hoạt động.

Mẫu cấu hình và biến

Hãy suy nghĩ về các vai trò của các thiết bị mạng trong một doanh nghiệp. Các router thường kết nối với cả mạng LAN và một hoặc nhiều mạng LAN. Bạn có thể có một số lượng nhỏ các Router lớn hơn được kết nối với mạng WAN tại các trang web lớn, có đủ năng lượng để xử lý tốc độ gói lớn hơn. Các trang web nhỏ hơn, như các văn phòng chi nhánh, có thể có các Router nhỏ, có thể với một giao diện WAN và một giao diện LAN duy nhất. Tuy nhiên, chúng ta có thể có một số lượng lớn các Router chi nhánh nhỏ trong mạng.

Đối với bất kỳ bộ thiết bị nào có cùng vai trò, cấu hình có thể giống nhau. Chẳng hạn, một bộ các router văn phòng chi nhánh đều có thể có cùng cấu hình chính xác cho một số dịch vụ IP, như NTP hoặc SNMP. Nếu sử dụng cấu hình giao diện OSPF, các Router trong cùng khu vực OSPF và có ID giao diện giống hệt nhau có thể có cấu hình OSPF giống hệt nhau.

Ví dụ 19-1 hiển thị đoạn trích cấu hình từ Router nhánh, với các phần duy nhất của cấu hình được tô sáng. Tất cả các phần không được đánh dấu có thể giống nhau trên tất cả các Router văn phòng chi nhánh khác của cùng một mô hình (có cùng số giao diện). Một doanh nghiệp có thể có hàng chục hoặc hàng trăm Router chi nhánh với cấu hình gần giống nhau.

Ví dụ 19-1 Cấu hình Router BR1, với các giá trị duy nhất được tô sáng

Các công cụ quản lý cấu hình có thể tách các thành phần của cấu hình thành các phần chung cho tất cả các thiết bị có vai trò đó (mẫu) so với các phần duy nhất cho bất kỳ một thiết bị nào (các biến). Sau đó, các kỹ sư có thể chỉnh sửa tệp mẫu chuẩn cho vai trò của thiết bị dưới dạng tệp riêng biệt so với từng tệp biến của thiết bị. Sau đó, công cụ quản lý cấu hình có thể xử lý khuôn mẫu và các biến để tạo tệp cấu hình lý tưởng cho từng thiết bị, như trong Hình 19-6, cho thấy các tệp cấu hình đang được xây dựng cho các Router nhánh BR21, BR22 và BR23.

Hình 19-6 Khái niệm: Các mẫu cấu hình và biến

Để hiểu rõ hơn một chút, ví dụ 19-2 hiển thị tệp mẫu có thể được Ansible sử dụng cho cấu hình được hiển thị trong ví dụ 19-1. Mỗi công cụ chỉ định ngôn ngữ sẽ sử dụng cho từng loại tệp, với Ansible sử dụng ngôn ngữ Jinja2 cho các mẫu.

Ví dụ mẫu 19-2 Jinja2 với các biến dựa trên ví dụ 19-1

 

 

Để cung cấp các giá trị cho một thiết bị, Ansible gọi để xác định các tệp biến bằng YAML, như trong ví dụ 19-3. Tệp hiển thị cú pháp để xác định các biến được hiển thị trong cấu hình hoàn chỉnh trong Ví dụ 19-1, nhưng bây giờ được xác định là biến.

Ví dụ 19-3 Tệp biến YAML dựa trên ví dụ 19-2

Hệ thống quản lý cấu hình xử lý một template cộng với tất cả các biến liên quan để tạo ra cấu hình dự định cho thiết bị. Chẳng hạn, kỹ sư sẽ tạo và chỉnh sửa một tệp template mẫu giống như ví dụ 19-2, sau đó tạo và chỉnh sửa một tệp biến như ví dụ 19-3 cho mỗi Router văn phòng chi nhánh. Ansible sẽ xử lý các tệp để tạo các tệp cấu hình hoàn chỉnh như văn bản được hiển thị trong Ví dụ 19-1.

Sử dụng các mẫu cấu hình template có một số lợi thế lớn. Đặc biệt:

 

●       Mẫu template tăng sự tập trung vào việc có cấu hình tiêu chuẩn cho từng vai trò của thiết bị, giúp tránh những thiết bị được cấu hình duy nhất.

●       Các thiết bị mới có vai trò hiện tại có thể được triển khai dễ dàng bằng cách sao chép một tệp biến trên mỗi thiết bị hiện có và thay đổi các giá trị.

●       Mẫu template cho phép khắc phục sự cố dễ dàng hơn vì các sự cố với một mẫu template tiêu chuẩn sẽ tìm và khắc phục sự cố với tất cả các thiết bị sử dụng cùng một mẫu.

●       Theo dõi các phiên bản tệp cho mẫu so với các tệp biến cũng cho phép xử lý sự cố dễ dàng hơn. Các vấn đề với thiết bị có thể được nghiên cứu để tìm các thay đổi trong cài đặt của thiết bị, tách biệt với mẫu cấu hình tiêu chuẩn.

Tập tin điều khiển tự động cấu hình

Các công cụ quản lý cấu hình cũng cung cấp các phương thức khác nhau để xác định logic và các quy trình cho công cụ biết những thay đổi cần thực hiện, với thiết bị nào và khi nào. Chẳng hạn, một kỹ sư có thể chỉ đạo một công cụ thực hiện các thay đổi trong cuối tuần. Logic tương tự có thể chỉ định một tập hợp con của các thiết bị.

 

Hình 19-7 Các tệp quan trọng được sử dụng bởi Công cụ quản lý cấu hình

ANSIBLE, PUPPET, CHEF

Ansible, Puppet và Chef là các công cụ phần mềm quản lý cấu hình. Bạn có thể mua từng công cụ, với các biến thể trên gói đó. Tuy nhiên, tất cả chúng cũng có các tùy chọn miễn phí khác nhau cho phép bạn tải xuống và tìm hiểu về các công cụ, mặc dù bạn có thể cần chạy Linux vì một số công cụ không chạy trong Windows.

Về tên, hầu hết mọi người sử dụng các từ Ansible, Puppet và Chef để chỉ các công ty cũng như các sản phẩm quản lý cấu hình chính của họ. Cả ba đều nổi lên như một phần của quá trình chuyển đổi từ máy chủ dựa trên phần cứng sang máy chủ ảo hóa, điều này đã làm tăng đáng kể số lượng máy chủ và tạo ra nhu cầu tự động hóa phần mềm để tạo, định cấu hình và loại bỏ VM. Cả ba sản xuất một hoặc nhiều sản phẩm phần mềm quản lý cấu hình đồng nghĩa với việc các công ty của họ sẽ có nhiều hướng phát triển.

Ansible

Để sử dụng Ansible (www.ansible.com), bạn cần cài đặt Ansible trên một số máy tính: Mac, Linux hoặc Linux VM trên máy chủ Windows. Bạn có thể sử dụng phiên bản nguồn mở miễn phí hoặc sử dụng phiên bản máy chủ Ansible Tower có trả phí.

Sau khi được cài đặt, bạn tạo một số tệp văn bản, chẳng hạn như sau:

●       Playbooks: Những tệp này cung cấp kịch bản hành động và logic về những gì Ansible nên làm.

●       Inventory: Các tệp này cung cấp tên máy chủ của thiết bị cùng với thông tin về từng thiết bị, như vai trò của thiết bị.

●       Templates: Sử dụng ngôn ngữ Jinja2, các mẫu đại diện cho cấu hình của thiết bị nhưng có các biến.

●       Variables: Sử dụng YAML, một tệp có thể liệt kê các biến mà Ansible sẽ thay thế thành các mẫu.

Theo như cách Ansible hoạt động để quản lý các thiết bị mạng, nó sử dụng kiến ​​trúc không có tác nhân (agentless). Điều đó có nghĩa là Ansible không dựa vào bất kỳ agent nào đang chạy trên thiết bị mạng. Thay vào đó, Ansible dựa vào các tính năng điển hình trong các thiết bị mạng, cụ thể là SSH và / hoặc NETCONF để thực hiện các thay đổi và trích xuất thông tin. Khi sử dụng SSH, nút điều khiển Ansible thực sự thay đổi thiết bị như bất kỳ người dùng SSH nào khác sẽ làm, nhưng thực hiện công việc với mã Ansible, thay vì với con người.

Ansible có thể được mô tả là sử dụng mô hình đẩy (hình 19-8) thay vì mô hình kéo (như Puppet và Chef). Sau khi cài đặt Ansible, một kỹ sư cần tạo và chỉnh sửa tất cả các tệp Ansible khác nhau, bao gồm Playbook. Các bước đó có thể bao gồm định cấu hình một hoặc nhiều thiết bị cho mỗi tệp khác nhau (bước 3), với nút điều khiển được xem là đẩy cấu hình cho thiết bị.

 

Hình 19-8 Mô hình đẩy Ansible

Giống như với tất cả các công cụ quản lý cấu hình khác, Ansible có thể thực hiện cả việc cung cấp cấu hình (cấu hình thiết bị sau khi thay đổi được thực hiện trong tệp) và giám sát cấu hình (kiểm tra xem liệu cấu hình thiết bị có khớp với cấu hình lý tưởng trên nút điều khiển không). Tuy nhiên, kiến ​​trúc Ansible đã phù hợp hơn với việc cung cấp cấu hình, như trong hình. Để thực hiện giám sát cấu hình, Ansible sử dụng các mô-đun logic phát hiện và liệt kê các khác biệt về cấu hình, sau đó, playbook xác định hành động nào cần thực hiện (cấu hình lại hoặc thông báo).

Puppet

Để sử dụng Puppet (www.puppet.com), như Ansible, chúng ta hãy bắt đầu bằng cách cài đặt Puppet trên Linux. Bạn có thể cài đặt nó trên máy chủ Linux của riêng bạn, nhưng với mục đích sản xuất, thông thường bạn sẽ cài đặt nó trên máy chủ Linux có tên là Puppet master. Giống như với Ansible, bạn có thể sử dụng phiên bản nguồn mở miễn phí với các phiên bản trả phí có sẵn. Bạn có thể bắt đầu học Puppet mà không cần máy chủ riêng để học và kiểm tra.

Sau khi cài đặt, Puppet cũng sử dụng một số tệp văn bản quan trọng với các thành phần khác nhau, chẳng hạn như sau:

●       Manifest: Đây là tệp văn bản có thể đọc được trên Master Puppet, sử dụng ngôn ngữ được xác định bởi Puppet, được sử dụng để xác định trạng thái cấu hình mong muốn của thiết bị.

●       Resource, Class, Module: Các thuật ngữ này đề cập đến các thành phần của tệp kê khai, với thành phần lớn nhất (mô-đun) được tạo thành từ các lớp nhỏ hơn, lần lượt bao gồm các tài nguyên. Các thuật ngữ này đề cập đến các thành phần của bảng kê khai, với thành phần lớn nhất (mô-đun) được tạo thành từ các lớp nhỏ hơn, lần lượt bao gồm các tài nguyên.

●       Templates: Sử dụng ngôn ngữ dành riêng cho miền Puppet, các tệp này cho phép Puppet tạo tệp kê khai (và mô-đun, lớp và tài nguyên) bằng cách thay thế các biến vào mẫu.

Một cách để suy nghĩ về sự khác biệt giữa cách tiếp cận Ansible và Puppet, đó là Playbooks Ansible sử dụng một ngôn ngữ bắt buộc, trong khi Puppet sử dụng ngôn ngữ khai báo. Chẳng hạn, với Ansible, playbook sẽ liệt kê các tác vụ và lựa chọn dựa trên các kết quả đó, như xác định cấu hình tất cả các Router nhánh ở những vị trí này và nếu xảy ra lỗi cho bất kỳ thiết bị nào, hãy thực hiện các tác vụ bổ sung này cho thiết bị đó. Puppet thường sử dụng kiến ​​trúc dựa trên agent để hỗ trợ thiết bị mạng. Một số thiết bị mạng cho phép hỗ trợ Puppet thông qua một agent trên thiết bị. Tuy nhiên, không phải mọi hệ điều hành của Cisco đều hỗ trợ các agent, vì vậy Puppet giải quyết vấn đề đó bằng cách sử dụng một agent proxy chạy trên một số máy chủ bên ngoài (được gọi là hoạt động không có tác nhân).

Hình 19-9 Hoạt động dựa trên agent và agentless cho Puppet

Trên trang web Puppet, Puppet hỗ trợ cả kiến ​​trúc dựa trên tác nhân và không có tác nhân, với kiến ​​trúc không có tác nhân là trường hợp sử dụng một tác nhân bên ngoài cho thiết bị mạng, như được hiển thị trong phần dưới của Hình 19-9.

Puppet sử dụng mô hình kéo để làm cho cấu hình đó xuất hiện trong thiết bị, như trong Hình 19-10. Sau khi cài đặt, các bước này xảy ra:

Bước 1. Người kỹ sư tạo và chỉnh sửa tất cả các tệp trên máy chủ Puppet.

Bước 2. Kỹ sư cấu hình và kích hoạt tác nhân trên thiết bị hoặc tác nhân proxy cho từng thiết bị.

Bước 3. Agent trên thiết bị lấy thông tin chi tiết từ máy chủ, thông báo cho thiết bị biết cấu hình của nó là gì.        

Bước 4. Nếu tác nhân cấu hình của thiết bị cần cập nhật, Puppet thực hiện các thao tác kéo bổ sung để có được tất cả các chi tiết cần thiết, với agent cập nhật cấu hình thiết bị.

 

Hình 19-10 Mô hình kéo với Puppet

Chef

Chef (www.chef.io), như với Ansible và Puppet, tồn tại dưới dạng các gói phần mềm. Chef (công ty) cung cấp một số sản phẩm, với Chef Automate là sản phẩm mà hầu hết mọi người gọi đơn giản là Chef. Như với Puppet, trong hệ thống mạng, bạn có thể chạy Chef dưới dạng máy chủ (được gọi là chế độ client-server), với nhiều máy trạm Chef được nhân viên kỹ thuật sử dụng để xây dựng các tệp Chef được lưu trữ trên máy chủ Chef. Tuy nhiên, bạn cũng có thể chạy Chef ở chế độ độc lập (được gọi là Chef Zero), rất hữu ích khi bạn mới bắt đầu và học trong phòng lab. Khi Chef được cài đặt, bạn tạo một số tệp văn bản với các thành phần khác nhau, như sau:

●       Resource: Các đối tượng cấu hình có trạng thái được quản lý bởi Chef; chẳng hạn, một tập hợp các lệnh cấu hình cho một thiết bị mạng.

●       Recipe: Logic Chef áp dụng cho các tài nguyên để xác định thời điểm, cách thức và các hành động trên tài nguyên.

●       Cookbooks: Một bộ các công thức về cùng loại công việc, được nhóm lại với nhau để quản lý và chia sẻ dễ dàng hơn.

●       Runlist: Danh sách các công thức nên được chạy trên một thiết bị nhất định.

Chef sử dụng một kiến ​​trúc tương tự như Puppet. Đối với các thiết bị mạng, mỗi thiết bị được quản lý (được gọi là nút Chef hoặc Chef client) chạy một tác nhân agent. Tác nhân thực hiện giám sát cấu hình trong đó client lấy các công thức và tài nguyên từ máy chủ Chef và sau đó điều chỉnh cấu hình của nó để đồng bộ.

Tóm tắt các công cụ quản lý cấu hình

Cả ba trong số các công cụ quản lý cấu hình được liệt kê ở đây có một cơ sở người dùng tốt và các thế mạnh khác nhau. Đối với việc sử dụng chúng để quản lý cấu hình thiết bị mạng, Ansible dường như được quan tâm nhất, sau đó là Puppet và sau đó là Chef. Kiến trúc agentless Ansible và việc sử dụng SSH cung cấp hỗ trợ cho nhiều loại thiết bị của Cisco. Mô hình không có tác nhân Puppet cũng tạo ra sự hỗ trợ rộng rãi cho các thiết bị của Cisco.

Bảng 19-2 tóm tắt một vài ý tưởng phổ biến nhất về mỗi trong số ba công cụ quản lý cấu hình tự động. Lưu ý rằng cột cho Puppet giả sử một tác nhân trên thiết bị.

 

Bảng 19-2 So sánh Ansible, Puppet và Chef 

* Puppet có thể sử dụng một tác nhân trong thiết bị hoặc một tác nhân proxy bên ngoài cho các thiết bị mạng.

DEVNET LABS

Trang web Cisco DevNet (https://developer.cisco.com) Trang web miễn phí bao gồm các bài tập và môi trường lab. Bạn có thể tìm hiểu rất nhiều về quản lý cấu hình và đặc biệt là Ansible với một vài trải nghiệm lab trên trang DevNet.