Được xây dựng dựa trên nền tảng kiến thức DevOps của chúng tôi, trong bài viết này, tôi sẽ giới thiệu cho các bạn phiên bản thực tế của một quy trình phân phối NetDevOps hoàn chỉnh.
Trước khi chúng ta tiếp tục, hãy để tôi tạo tiền đề một chút bằng cách giải quyết một vài điều khoản mới. Nhìn chung, NetDevOps Pipeline bao gồm bốn bước chính, Tạo, Xây dựng, Kiểm tra và Triển khai cấu hình dưới dạng mã. Trong các bước đó, chúng tôi sẽ thực hiện cả kiểm tra đơn vị và tích hợp để đảm bảo rằng sự thay đổi mạng của chúng tôi sẽ không Kaput mạng sản xuất hoặc dẫn đến thời gian ngừng hoạt động. Các giai đoạn Xây dựng và Thử nghiệm kết hợp tạo nên đường dẫn NetDevOps CICD tự động của chúng tôi. Ở đây chúng tôi không cố gắng phát minh lại thứ gì đó ở đây với NetDevOps Pipeline, toàn bộ quá trình không có gì khác ngoài việc định vị lại chuỗi công cụ DevOps và khái niệm Cơ sở hạ tầng dưới dạng Mã hoặc IaC, để thể hiện cấu hình như mã trong khi tận dụng khả năng lập trình mạng.
Cuối cùng nhưng không kém phần quan trọng, nguyên tắc hoạt động đằng sau NetDevOps Pipeline dựa trên thực tế là số liệu cơ bản nhất để đánh giá kết quả thay đổi mạng là thời gian hoạt động của mạng.
Bây giờ, bạn có thể chia quá trình thực thi NetDevOps Pipeline tổng thể thành bốn bước chính.
Bước 1. Nó bao gồm tạo, xác minh, cam kết và đẩy thay đổi cấu hình của bạn trong nhánh cấu hình phát triển. Nhánh phát triển có ý nghĩa làm gì? Trong một tổ chức, nơi các nhà phát triển đang viết các tính năng mới hoặc sửa lỗi, họ làm như vậy bằng cách sao chép hoặc rút một nhánh chính làm nhánh phát triển. Sau đó, họ thực hiện tất cả các thay đổi trước tiên vào nhánh nhà phát triển đó, thay vì thêm chúng trực tiếp main or master code. Bây giờ, hãy truy cập lại chuỗi công cụ DevOps. Trong bước này, chuỗi công cụ của bạn sẽ bao gồm GitHub, Ansible và một công cụ giúp bạn xây dựng cấu trúc liên kết để kiểm tra đơn vị, ví dụ: sử dụng Vagrant hoặc Cisco VIRL trong trường hợp thiết bị hoặc đơn vị đó là của Cisco. Hãy để tôi làm rõ kiểm thử đơn vị ở đây. Trong bối cảnh này, kiểm thử đơn vị có nghĩa là xác minh và xác thực thay đổi cấu hình mà bạn vừa thực hiện với tư cách là một NetDevOps. Loại kiểm thử đơn vị này còn được gọi là kiểm thử hộp trắng. Sau khi kiểm tra đơn vị hoàn tất thành công, bạn sẽ cần hợp nhất và cam kết cấu hình đã xác thực của mình vào nhánh cấu hình nhà phát triển, một lần nữa bằng cách sử dụng GitHub hoặc một công cụ tương tự khác. Khi bạn thực hiện push, giả sử bạn sử dụng lệnh “git push”, sau đó cấu hình của bạn sẽ được đưa vào công cụ xây dựng của bạn, chẳng hạn như Jenkins hoặc Drone, là một nền tảng CICD mã nguồn mở khác. Sau khi bạn “push” cấu hình của mình, Trước khi tiếp tục, hãy để tôi làm rõ một trong nhiều biệt ngữ DevOps. Git hoặc GitHub. như được sử dụng trong ngữ cảnh này, được gọi là Hệ thống kiểm soát phiên bản hoặc VCS và cũng là Quản lý kiểm soát nguồn hoặc SCM. Bây giờ, SCM mà tôi vừa đề cập, không bị nhầm lẫn với Quản lý cấu hình phần mềm, một chủ đề lớn hơn nhiều và riêng biệt.
Bước 2. Trong bước 1, ngay sau khi bạn thực hiện “git push”, git sẽ tiếp cận với công cụ xây dựng của bạn bằng cách sử dụng cùng một nhánh nhà phát triển. Công cụ xây dựng của bạn sẽ kéo xuống một bản sao của nhánh nhà phát triển của bạn và bắt đầu thực hiện đường dẫn mà bạn đã định cấu hình nó.
Bước đầu tiên, trong đường dẫn CICD của bạn, có thể sẽ bắt đầu cấu trúc liên kết mạng thử nghiệm mô phỏng của bạn. Làm thế nào mà điều đó xảy ra? Rõ ràng, bạn sẽ sử dụng cấu trúc liên kết ảo, vì vậy công cụ xây dựng của bạn sẽ cần sử dụng Vagrant hoặc Cisco VIRL để thực hiện hành động đó. Sau khi hoàn thành, tùy thuộc vào cấu hình đường ống, máy chủ xây dựng của bạn có thể sử dụng Ansible để định cấu hình mạng thử nghiệm ảo mà bạn vừa xây dựng. Để tiến hành kiểm tra tích hợp hiệu quả, bạn sẽ cần một chiến lược kiểm tra, chẳng hạn như dưới dạng một vở kịch Ansible, cho phép bạn xác nhận rằng mạng thử nghiệm của bạn đang hoạt động như mong đợi với cấu hình mạng đã sửa đổi. Hãy để tôi làm rõ. Mục đích của thử nghiệm tích hợp, trái ngược với thử nghiệm đơn vị, là để đảm bảo rằng toàn bộ mạng hiện có tiếp tục hoạt động mà không có bất kỳ trục trặc nào sau khi các thay đổi cấu hình của bạn được cam kết. Bây giờ, trước khi bạn nói, wow tôi cũng cần phải viết kế hoạch kiểm tra!
Nghe đây, trong một tổ chức từ trung bình đến lớn, bạn có thể mong đợi các sách phát thử nghiệm tích hợp được viết bởi các kỹ sư kiểm tra chất lượng chuyên dụng. Sau khi hoàn tất xác thực kiểm tra thành công, công cụ xây dựng của bạn sẽ gỡ bỏ cấu trúc liên kết mạng kiểm tra tích hợp và hợp nhất nhánh nhà phát triển đã xác thực vào nhánh chính của bạn.
Bước 3. Hệ thống xây dựng của bạn xây dựng nhánh chính và lặp lại tất cả các bước đã thực hiện trong bước 2. Hãy xem lại các bước một lần nữa. Máy chủ xây dựng của bạn sẽ khởi động đường ống dẫn CICD bằng cách tạo phiên bản mô phỏng của mạng sản xuất của bạn, xác thực thay đổi mạng của bạn như một phần của nhánh chính bằng cách sử dụng cấu trúc liên kết thử nghiệm, nếu mọi thứ diễn ra tốt đẹp, nó sẽ gỡ cấu trúc liên kết thử nghiệm và hoàn tất việc xây dựng cấu hình chính chi nhánh.
Bước 4. Sau khi xây dựng nhánh chính được thực hiện thành công, tùy thuộc vào cấu hình đường dẫn của bạn, máy chủ xây dựng của bạn sẽ đẩy cấu hình của bạn vào mạng sản xuất của bạn bằng cách sử dụng một playbook Ansible khác.
Mặc dù tất cả những điều này nghe có vẻ quá sức nhưng hãy để tôi đảm bảo với bạn rằng một khi bạn đã định cấu hình một đường dẫn và các sách phát tương ứng một vài lần, tất cả sẽ trở nên dễ hơn đối với bạn. Ngoài bước đầu tiên, nơi bạn tạo, xác minh, cam kết và đẩy thay đổi mạng của mình như một phần của nhánh nhà phát triển, mọi thứ khác được hệ thống xây dựng của bạn xử lý tự động, như một phần của đường ống CICD và đó là nơi bạn thấy giá trị thực về cả tốc độ và độ chính xác của việc triển khai thay đổi mạng.
Bây giờ, cuối cùng nhưng không kém phần quan trọng, tôi mời bạn đến và tham gia cùng tôi trên Full Stack Networker Blog. Tôi sẽ sớm thảo luận chi tiết hơn về quy trình phân phối NetDevOps cùng với các sách phát Ansible thực tế và cấu hình chuỗi công cụ.