Назад | Перейти на главную страницу

Составной ресурс Powershell DSC, частичная конфигурация или роли. Какой подход лучше всего поддерживать?

Мне немного сложно понять, какой подход лучше всего подходит для создания конфигураций на основе Powershell DSC.

Похоже, что частичные конфигурации предназначены для того, чтобы несколько человек / команд могли создавать конфигурации для своих собственных политик / конфигураций. В этом есть смысл, но я видел, как люди использовали этот подход для создания и, по сути, создания модулей, чтобы структурировать свой код, чтобы он не был таким монолитным. Это действующий подход?

Что касается составных ресурсов и ролей, кажется, что вы могли бы использовать эти два метода реализации вместе. Вы можете создать составной ресурс, скажем, создать веб-сервер, а затем назначить роль узлу для применения ресурса веб-сервера. Будет ли это правильный подход?

Существуют ли какие-то строительные леса, на которых можно построить что-то подобное?

Я смотрел на https://github.com/Microsoft/DscScaffolding и https://github.com/gaelcolas/DscInfraSample, но, насколько я могу судить, репозиторий DSCScaffolding не использует роли, а DscInfraSample, похоже, использует роли, но я не мог заставить его построить, поэтому не мог действительно увидеть, что он на самом деле делает .

Мой главный вопрос: как лучше всего подойти к Powershell DSC и как лучше всего организовать свои конфигурации для реального мира, чтобы их можно было поддерживать?

Я использую его в своей работе для применения конфигураций к серверам Linux (CentOS) и Windows. Я использую метод настройки push и режим ApplyAndMonitor.

В основном я создаю модуль под названием DSCTools и отдельную функцию конфигурации, которая содержит в себе фактические конфигурации.

DSCTools выполняет следующее: - принимает параметр имени компьютера - проверяет Active Directory или ввод вручную, чтобы получить атрибуты этого компьютера. (т.е. это SFTP-сервер Linux или файловый сервер Windows) - проверяет, нужно ли устанавливать модули на удаленный компьютер перед применением конфигурации - создает файл MOF - подталкивает конфигурацию

Конфигурация - это, по сути, гигантская функция, которая, в моей работе, представляет собой файл PS1 длиной около 3000 строк. Я использую код Visual Studio и сворачивание кода, чтобы свернуть его (Ctrl + K и Ctrl + 0), а затем на высоком уровне я могу видеть все различные типы серверов.

Сохраняя все это в одной конфигурации, я могу иметь такие утверждения, как «Все узлы, не являющиеся серверами AD, получают это» и «Все узлы, являющиеся серверами AD, получают это».

В будущем я планирую разделить конфигурации Linux и Windows на два отдельных файла, поскольку у них мало общего. Также имейте в виду, что Linux пока не поддерживает частичные конфигурации.

Для Windows может быть полезно несколько конфигураций. Например, у вас может быть «базовая» конфигурация, которую получают все серверы, а затем отдельная конфигурация «Безопасность», в которой есть ваши конфигурации соответствия CIS / DISA-STIG.

Затем у меня есть отдельный инструмент для ведения журнала, который проверяет рабочие журналы Powershell DSC на наличие сбоев. это позволит мне точно узнать, какой параметр, который я указал, не соответствует. Например, возможно, разработчик зашел и удалил файл конфигурации или параметр реестра.

Я также занимаюсь управлением версиями, используя базовый репозиторий общего файлового ресурса, и могу видеть, как конфигурация менялась с течением времени.

Я потратил последние 2-3 года на изучение Powershell и DSC, и это очень помогает в моей работе - управлять всем и намного быстрее.