Có gì khác biệt / tốt hơn về kịch bản DSC thường xuyên vs

Tôi đã xem một video trên ITPro.tv về Cấu hình trạng thái mong muốn của PowerShell . Họ giới thiệu nó, và chạy một kịch bản hiệu quả. Tuy nhiên, đây cũng là lần giới thiệu kịch bản đầu tiên (thực sự) của họ, vì vậy tôi đã không nhận ra sự khác biệt giữa DSC và kịch bản thông thường. Tôi đã thực hiện một số kịch bản thông thường trước đây và có lẽ họ không có ví dụ tuyệt vời đó; có vẻ như một tập lệnh thông thường có thể cài đặt một vai trò / tính năng và sao chép một số tệp tốt. Tôi không thấy lợi ích của DSC so với chỉ một kịch bản. Ngoài việc một cỗ máy có thể thăm dò một số loại thay đổi mà họ không đề cập trong thực tế, chỉ là trên lý thuyết.

Những lợi ích của DSC so với các tập lệnh truyền thống; ví dụ "cài đặt vai trò, sao chép tập tin"?

• Với PowerShell, bạn có thể kết nối với các máy từ xa và bảo họ làm công cụ, vì vậy đó không phải là độc quyền của DSC.
• Với DSC, có vẻ như bạn đang thực hiện một số phần biên dịch để tạo tệp mof, và sau đó bạn chạy nó từ trình bao sau tập lệnh, có vẻ như là một bước không cần thiết.
• Các tổng quan MSDN đọc như một tổng quan về PowerShell, và tôi không thấy đặc điểm khác biệt.

Như bạn đã nói, bạn có thể làm khá nhiều thứ bạn sẽ làm với DSC, với mã powershell thẳng.

Nhưng, DSC là tất cả về quản lý cấu hình.

Quản lý cấu hình là về các mẫu và thực hành sử dụng mã và các hệ thống khác nhau để đảm bảo hệ thống ở trạng thái cụ thể. Tham chiếu 1 2

Một điều quan trọng về quản lý cấu hình là sự ổn định. Có nghĩa là mã mô tả hệ thống của bạn trong hệ thống quản lý cấu hình sẽ được kiểm tra và chạy theo hệ thống của bạn theo định kỳ. Rất nhiều tập lệnh cơ bản không được thiết kế tốt và sẽ thực hiện đúng vào lần đầu tiên bạn sử dụng nó để định cấu hình một hệ thống, nhưng lần sau chúng sẽ bị lỗi, trùng lặp mọi thứ, v.v. Các hệ thống quản lý cấu hình lý tưởng sẽ trừu tượng hóa một phần lớn mã kiểm tra và kiểm tra trạng thái mà bạn phải thêm thủ công vào tập lệnh, để làm cho tập lệnh của bạn trở nên bình thường.

Một điều quan trọng khác về DSC và nhiều hệ thống quản lý cấu hình khác là về việc tạo ra các tài nguyên có thể sử dụng lại thực sự làm công việc có thể chia sẻ với bất kỳ ai và mọi người trên thế giới. Theo cách này, 'cấu hình' thực sự của bạn chỉ nên là một vài chi tiết cụ thể dành riêng cho môi trường của bạn. Điều này cũng có nghĩa là bạn cần phải viết ít mã hơn rất nhiều, vì bạn có thể sử dụng lại những thứ đã được sử dụng và hiệu đính bởi nhiều người khác.

Tôi đã bao gồm một vài liên kết ở trên, nhưng có nhiều trang web tốt bạn có thể tìm thấy trên Internet về lý thuyết hệ thống quản lý cấu hình. Lý thuyết chung áp dụng cho tất cả các hệ thống quản lý cấu hình (con rối, đầu bếp, dsc, ansible, v.v.) nó chắc chắn đáng để học hỏi và đáng sử dụng trong hầu hết các môi trường.

Tôi khuyên bạn nên xem https://docs.microsoft.com/en-us/powershell/dsc/dscforengineers#i-have-powershell-why-do-i-need-desired-state-configuration .

Tôi đã từng làm devops như một người dẫn đầu dự án C # kể từ trước khi nó được gọi như vậy. Tôi đã viết hàng tá "thiết lập chia sẻ" này và "tạo một ứng dụng trong IIS" và "kiểm tra xem IIS Rewrite có được cài đặt không". Tôi thường được yêu cầu làm điều đó bởi một người nghĩ rằng "Đó chỉ là một dòng mã để làm X." Nhưng nếu cái đó đã tồn tại thì sao? Điều gì xảy ra nếu các bước 1,3 đã tồn tại nhưng 2,4 không hoặc bước 2 (giả sử nhóm ứng dụng IIS) không được định cấu hình chính xác như lần trước?

Có, DSC yêu cầu bạn đặt tên cho mỗi "phần" của tập lệnh. Mà có vẻ tẻ nhạt lúc đầu. Nhưng nếu bạn không đặt tên cho nó thì công cụ DSC và các nhà cung cấp không thể cho bạn biết phần nào của tập lệnh mà nó mất quá nhiều thời gian hoặc phần nào của tập lệnh bị lỗi.

Nếu bạn đang thực hiện các thư mục, IIS, triển khai ứng dụng hoặc các tính năng của Windows, tôi khuyên bạn nên đầu tư một vài ngày để học DSC.