PowerShell Desired State Configuration. Назначение, возможности и использование::Журнал СА 12.2013
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 975
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1098
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 829
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 664
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1265
Комментарии: 0
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 PowerShell Desired State Configuration. Назначение, возможности и использование

Архив номеров / 2013 / Выпуск №12 (133) / PowerShell Desired State Configuration. Назначение, возможности и использование

Рубрика: Администрирование /  Инструменты

Сергей Яремчук СЕРГЕЙ ЯРЕМЧУК, автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС, grinder@samag.ru

PowerShell Desired State Configuration
Назначение, возможности и использование

Вместе с Windows Server 2012 R2 представлена и новая версия PowerShell 4.0. Ключевое решение – расширение Desired State Configuration

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

Мы можем указать, какие роли и компоненты необходимо установить, но понять, что чего-то в системе быть не должно, или контролировать последовательность операций текущими средствами так непросто. Даже при использовании готовых решений PowerShell Deployment Toolkit (PDT) требуется дальнейшее конфигурирование вручную. И, главное, администраторы Linux уже используют инструменты централизованного управления вроде Puppet [1] и Сhef [2], позволяющие с помощью созданных скриптов полностью контролировать состояние систем. Теперь подобная возможность реализована и для Windows. Идея «continuous deployments» (непрерывного развертывания) для Windows с появлением нового инструмента приобретает четкие очертания.

Возможности PowerShell Desired State Configuration

Новая функция PowerShell 4.0 – Desired State Configuration (DSC, Служба настройки требуемого состояния [3]), кроме выполнения классических операций (управление ролями и компонентами, реестром, переменными среды, каталогом, процессами, сервисами, учетными записями и выполнение сценариев PS), позволяет узнать текущую конфигурацию узла и исправить ее, если она не соответствует требуемой, или вернуть предыдущее состояние ОС.

Причем DSC будет частью Windows Management Framework (WMF) 4.0, а, значит, он будет работать не только в Windows Server 2012 R2 и 8, но и в более ранних Windows 7 SP1, Windows Server 2008 R2 SP1 и 2012.

В новых ОС функция PowerShell Remoting включена по умолчанию, в более ранних версиях нужно не забыть разрешить подключения:

PS> Enable-PSRemoting –Force

Процесс настройки систем с помощью DSC состоит из трех этапов. Вначале следует подготовить сценарий, в котором указывается конфигурация компьютеров – какие элементы должны или не должны быть установлены. Подойдет любой другой инструмент или язык третьей стороны, любая версия PowerShell, но, естественно, рекомендуется 4.0, в которой добавлены расширения синтаксиса, упрощающие процесс. Следующим шагом является компиляция MOF (Management Object Format) файла, в котором определяются WMI-классы и их свойства. Причем файл генерируется персонально, если сценарий описывает несколько систем, каждая получит только свой файл с конкретными установками. Файл распространяется на другие серверы с помощью PowerShell Remoting, групповых политик, централизованного URI, откуда его забирают клиенты, или любыми другими способами (в том числе и вручную), где он анализируется и используется для изменения настроек. Реализованы два метода обновлений:

  • Push – в этом режиме, используя командлет Start-DscConfiguration, применяется новая конфигурация к системе, используется по умолчанию;
  • Pull – система самостоятельно, через указанный интервал (по умолчанию 15 минут), проверяет наличие обновлений конфигурации на Pull-сервере.

Последний вариант очень интересен с точки зрения масштабируемости, так как позволяет легко контролировать состояние любого количества систем, включая виртуальные машины и мобильных клиентов. И в отличие от групповых политик настройки для целевых систем указываются более гибко и тонко.

Все действия на конечной системе выполняются с помощью ресурсов или провайдеров (по имени каталога), которые, собственно, и устанавливают роли и компоненты, параметры среды, копируют файлы, изменяют реестр, управляют сервисами и учетными записями, выполняют произвольные сценарии. Причем можно указывать зависимость ресурсов друг от друга, тогда некоторая настройка будет ожидать успешного окончания предыдущей операции. На сегодня таких провайдеров 12, подробно они описаны в документации [3], просмотреть их можно в C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredState-Configuration\PSProviders (см. рис. 1). В указанной папке нет каталога, соответствующего File-ресурсу, который является «встроенным». Очевидно, что это начало, ведь пока реализованы только провайдеры для первичных и самых востребованных операций, но в будущем их количество наверняка увеличится.

Рисунок 1. Файлы ресурсов DSC представляют собой модули PowerShell

Рисунок 1. Файлы ресурсов DSC представляют собой модули PowerShell

По сути, описания ресурсов представляют собой обычные модули PowerShell, поэтому их можно изменить по своему усмотрению и (что очень важно) создать своего провайдера. Это гораздо проще, чем, к примеру, написать расширение групповой политики.

Теперь разберем подробнее.

Статью целиком читайте в журнале «Системный администратор», №12 за 2013 г. на страницах 26-29.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru