Bài viết này là bài thứ sáu trong loạt bài “Cách kiểm soát cơ sở hạ tầng mạng của bạn”. Nội dung của tất cả các bài viết trong chuỗi và các liên kết có thể được tìm thấy .
Sau khi bỏ lại một số chủ đề, tôi quyết định bắt đầu một chương mới.
Tôi sẽ quay lại bảo mật sau. Ở đây tôi muốn thảo luận về một cách tiếp cận đơn giản nhưng hiệu quả mà tôi chắc chắn rằng, dưới hình thức này hay hình thức khác, có thể hữu ích cho nhiều người. Đây giống như một câu chuyện ngắn về việc tự động hóa có thể thay đổi cuộc đời của một kỹ sư như thế nào. Chúng ta sẽ nói về việc sử dụng các mẫu. Ở cuối có một danh sách các dự án của tôi, nơi bạn có thể thấy mọi thứ được mô tả ở đây hoạt động như thế nào.
DevOps cho mạng
Tạo cấu hình bằng tập lệnh, sử dụng GIT để kiểm soát các thay đổi đối với cơ sở hạ tầng CNTT, “tải lên” từ xa - những ý tưởng này xuất hiện đầu tiên khi bạn nghĩ về việc triển khai kỹ thuật của phương pháp DevOps. Những lợi thế là rõ ràng. Nhưng thật không may, cũng có những nhược điểm.
Cách đây hơn 5 năm, các nhà phát triển của chúng tôi, những nhà mạng, đã đến gặp chúng tôi với những đề xuất này, chúng tôi không hề hài lòng.
Tôi phải nói rằng chúng tôi thừa hưởng một mạng lưới khá đa dạng, bao gồm thiết bị từ khoảng 10 nhà cung cấp khác nhau. Thật thuận tiện khi định cấu hình một số thứ thông qua cli yêu thích của chúng tôi, nhưng ở những thứ khác, chúng tôi thích sử dụng GUI hơn. Ngoài ra, quá trình làm việc lâu dài trên thiết bị “hoạt động” đã dạy chúng tôi cách kiểm soát thời gian thực. Ví dụ: khi thực hiện thay đổi, tôi cảm thấy thoải mái hơn nhiều khi làm việc trực tiếp thông qua cli. Bằng cách này, tôi có thể nhanh chóng nhận thấy đã xảy ra sự cố và khôi phục các thay đổi. Tất cả điều này đều mâu thuẫn với ý tưởng của họ.
Các câu hỏi khác cũng được đặt ra, chẳng hạn như giao diện có thể thay đổi đôi chút theo từng phiên bản phần mềm. Điều này cuối cùng sẽ khiến tập lệnh của bạn tạo "cấu hình" sai. Tôi không muốn sử dụng sản xuất để "chạy vào".
Hoặc làm thế nào để hiểu rằng các lệnh cấu hình đã được áp dụng chính xác và phải làm gì trong trường hợp xảy ra lỗi?
Tôi không muốn nói rằng tất cả những vấn đề này đều không thể giải quyết được. Chỉ cần nói “A” cũng có thể nói “B” và nếu bạn muốn sử dụng các quy trình tương tự để kiểm soát thay đổi như trong quá trình phát triển, thì bạn cần phải có môi trường phát triển và dàn dựng ngoài sản xuất. Sau đó, cách tiếp cận này có vẻ hoàn tất. Nhưng nó sẽ có giá bao nhiêu?
Nhưng có một tình huống khi những nhược điểm trên thực tế đã được san bằng và chỉ còn lại những ưu điểm. Tôi đang nói về công việc thiết kế.
Dự án
Trong hai năm qua, tôi đã tham gia dự án xây dựng trung tâm dữ liệu cho một nhà cung cấp lớn. Tôi chịu trách nhiệm về F5 và Palo Alto trong dự án này. Theo quan điểm của Cisco, đây là “thiết bị của bên thứ 3”.
Đối với cá nhân tôi, có hai giai đoạn riêng biệt trong dự án này.
Giai đoạn đầu tiên
Năm đầu tiên tôi bận rộn vô tận, tôi làm việc cả đêm lẫn cuối tuần. Tôi không thể ngẩng đầu lên được. Áp lực từ ban quản lý và khách hàng rất mạnh mẽ và liên tục. Với một thói quen liên tục, tôi thậm chí không thể cố gắng tối ưu hóa quy trình. Nó không chỉ và không quá nhiều về cấu hình của thiết bị như việc chuẩn bị tài liệu thiết kế.
Những cuộc thử nghiệm đầu tiên đã bắt đầu và tôi sẽ ngạc nhiên khi thấy có bao nhiêu lỗi nhỏ và sai sót đã xảy ra. Tất nhiên, mọi thứ đều hoạt động, nhưng có một chữ cái bị thiếu trong tên, có một dòng bị thiếu trong lệnh... Các bài kiểm tra cứ lặp đi lặp lại và tôi đã phải vật lộn liên tục hàng ngày với các lỗi, bài kiểm tra và tài liệu .
Điều này đã diễn ra trong một năm. Theo tôi hiểu, dự án không hề dễ dàng đối với tất cả mọi người, nhưng dần dần khách hàng ngày càng hài lòng hơn và điều này giúp có thể thuê thêm các kỹ sư có khả năng tự đảm nhận một phần công việc.
Bây giờ chúng ta có thể nhìn xung quanh một chút.
Và đây là sự khởi đầu của giai đoạn thứ hai.
Giai đoạn thứ hai
Tôi quyết định tự động hóa quá trình này.
Điều tôi hiểu được từ cuộc trao đổi của tôi với các nhà phát triển vào thời điểm đó (và chúng tôi phải tri ân, chúng tôi có một đội ngũ mạnh) là định dạng văn bản, mặc dù thoạt nhìn có vẻ giống như một thứ gì đó đến từ thế giới của hệ điều hành DOS, nhưng có một số của những tài sản có giá trị.
Vì vậy, ví dụ, định dạng văn bản sẽ hữu ích nếu bạn muốn tận dụng tối đa GIT và tất cả các dẫn xuất của nó. Và tôi muốn.
Chà, có vẻ như bạn có thể chỉ cần lưu trữ một cấu hình hoặc danh sách các lệnh, nhưng việc thực hiện các thay đổi khá bất tiện. Ngoài ra, còn có một nhiệm vụ quan trọng khác trong quá trình thiết kế. Bạn nên có tài liệu mô tả toàn bộ thiết kế của mình (Thiết kế cấp thấp) và cách triển khai cụ thể (Kế hoạch triển khai mạng). Và trong trường hợp này, việc sử dụng các mẫu có vẻ là một lựa chọn rất phù hợp.
Vì vậy, khi sử dụng YAML và Jinja2, một file YAML với các tham số cấu hình như địa chỉ IP, số BGP AS,... hoàn thành xuất sắc vai trò của NIP, trong khi các mẫu Jinja2 bao gồm cú pháp tương ứng với thiết kế, tức là về cơ bản nó là một phản ánh của LLD.
Mất hai ngày để tìm hiểu YAML và Jinja2. Một vài ví dụ hay là đủ để hiểu cách thức hoạt động của nó. Sau đó, mất khoảng hai tuần để tạo tất cả các mẫu phù hợp với thiết kế của chúng tôi: một tuần cho Palo Alto và một tuần nữa cho F5. Tất cả điều này đã được đăng trên github của công ty.
Bây giờ quá trình thay đổi trông như thế này:
- đã thay đổi tệp YAML
- đã tạo tệp cấu hình bằng mẫu (Jinja2)
- được lưu trong kho lưu trữ từ xa
- đã tải cấu hình đã tạo lên thiết bị
- Tôi đã thấy một lỗi
- đã thay đổi tệp YAML hoặc mẫu Jinja2
- đã tạo tệp cấu hình bằng mẫu (Jinja2)
- ...
Rõ ràng là lúc đầu người ta dành rất nhiều thời gian cho việc chỉnh sửa, nhưng sau một hoặc hai tuần, điều này trở nên hiếm hoi.
Một thử nghiệm tốt và cơ hội để gỡ lỗi mọi thứ là mong muốn thay đổi quy ước đặt tên của khách hàng. Những người đã từng làm việc với F5 đều hiểu được tình hình khó khăn như thế nào. Nhưng đối với tôi mọi chuyện khá đơn giản. Tôi đã đổi tên trong tệp YAML, xóa toàn bộ cấu hình khỏi thiết bị, tạo một cái mới và tải nó lên. Mọi việc, kể cả sửa lỗi, đều mất 4 ngày: hai ngày cho mỗi công nghệ. Sau đó, tôi đã sẵn sàng cho giai đoạn tiếp theo, đó là tạo ra các trung tâm dữ liệu DEV và Staging.
Dev và dàn dựng
Dàn dựng thực sự tái tạo hoàn toàn quá trình sản xuất. Dev là một bản sao rút gọn được xây dựng chủ yếu trên phần cứng ảo. Một tình huống lý tưởng cho một cách tiếp cận mới. Nếu tôi tách thời gian tôi bỏ ra khỏi toàn bộ quá trình thì tôi nghĩ công việc chỉ mất không quá 2 tuần. Thời gian chính là chờ đợi đối phương và cùng nhau tìm kiếm vấn đề. Việc thực hiện của bên thứ 3 hầu như không được người khác chú ý. Thậm chí còn có thời gian để học điều gì đó và viết một vài bài báo về Habré :)
để tóm tắt
Vậy cuối cùng tôi có gì?
- Tất cả những gì tôi phải làm để thay đổi cấu hình là thay đổi một tệp YAML đơn giản, có cấu trúc rõ ràng với các tham số cấu hình. Tôi không bao giờ thay đổi tập lệnh python và rất hiếm khi (chỉ khi có lỗi) tôi thay đổi bản ghi nhiệt Jinja2
- Từ quan điểm tài liệu, đây là một tình huống gần như lý tưởng. Bạn thay đổi tài liệu (tệp YAML đóng vai trò là NIP) và tải cấu hình này lên thiết bị. Bằng cách này, tài liệu của bạn luôn được cập nhật
Tất cả điều này đã dẫn đến một thực tế là
- tỷ lệ lỗi đã giảm xuống gần như bằng 0
- 90 phần trăm thói quen đã biến mất
- tốc độ thực hiện đã tăng lên đáng kể
TRẢ TIỀN, F5Y, ACY
Tôi đã nói rằng một vài ví dụ là đủ để hiểu nó hoạt động như thế nào.
Đây là phiên bản ngắn (và tất nhiên đã được sửa đổi) của những gì được tạo ra trong quá trình làm việc của tôi.
= triển khai Palo Ađến từ Yaml = Palo Alto từ Yaml
= triển khai F5 từ Yam = F5 từ Yaml (sắp ra mắt)
= triển khai ACtôi từ Yam = F5 từ Yaml
Tôi sẽ nói thêm vài lời về ACY (đừng nhầm với ACI).
Những người đã từng làm việc với ACI đều biết rằng điều kỳ diệu này (và theo cách tốt nữa) chắc chắn không phải do các nhà mạng tạo ra :). Hãy quên mọi thứ bạn biết về mạng - nó sẽ không hữu ích cho bạn!
Dù có hơi cường điệu một chút nhưng nó đại khái truyền tải được cảm giác mà tôi đã không ngừng trải qua trong 3 năm qua khi làm việc với ACI.
Và trong trường hợp này, ACY không chỉ là cơ hội để xây dựng quy trình kiểm soát thay đổi (điều này đặc biệt quan trọng trong trường hợp ACI, vì nó được coi là phần trung tâm và quan trọng nhất trong trung tâm dữ liệu của bạn), mà còn mang lại cho bạn giao diện thân thiện với người dùng để tạo cấu hình.
Các kỹ sư trong dự án này sử dụng Excel để định cấu hình ACI thay vì YAML cho các mục đích tương tự. Tất nhiên, có những lợi ích khi sử dụng Excel:
- NIP của bạn trong một tệp
- biển hiệu đẹp, tạo cảm giác dễ chịu cho khách hàng khi nhìn vào
- bạn có thể sử dụng một số công cụ excel
Nhưng có một điểm trừ, và theo tôi nó nhiều hơn ưu điểm. Việc kiểm soát những thay đổi và điều phối công việc nhóm trở nên khó khăn hơn nhiều.
ACY thực sự là một ứng dụng có các phương pháp tương tự mà tôi đã sử dụng cho bên thứ 3 để định cấu hình ACI.
Nguồn: www.habr.com