Desired State Configuration

Konfigurujesz swiezo zainstalowany serwer... Jest ciekawie? Za pierwszym razem raczej tak. Za drugim pewnie tez, za to troche sprawniej. Od trzeciego do dziesiatego dochodzisz do wniosku, ze da sie to dobrze zrobic z zamknietymi oczami przy pomocy samych skrótów klawiaturowych. Oczywiscie serwer jest potem w 100% zgodny z firmowymi regulami konfiguracji, ustawiony w jedyny sluszny sposób i w ogóle idealny. Brzmi fantastycznie, ale przy wiekszej skali musza pojawic sie problemy. Na przyklad dwudziesty siódmy serwer okazuje sie skonfigurowany nieco inaczej, bo miales slabszy dzien, albo akurat rozlala sie kawa i w zamieszaniu zdarzylo sie przeskoczyc którys ze standardowo wykonywanych etapów. Albo kolega administrator wykonal dokladnie te same dzialania, tylko na koncu serwer ma inna konfiguracje.

Od kiedy mam do czynienia z produkcyjnymi serwerami Windows (czyli od polowy lat dziewiecdziesiatych), ciagle slysze, jak Microsoft jasno mówi, ze w takich sytuacjach powinnismy skorzystac z dostepnych bezplatnie, jedynych w swoim rodzaju, slusznych, skutecznych i w ogóle wspanialych narzedzi do centralnego zarzadzania konfiguracja. Malo tego! Sam o takich pieknych ideach wielokrotnie opowiadalem, na przyklad na poswieconej dokladnie temu tematowi sesji na konferencji MTS 2009.

A jak to wyglada naprawde? Mamy teoretycznie do dyspozycji dwa potezne narzedzia: skrypty i GPO. Teoretycznie wiemy jak ich uzywac. Teoretycznie da sie wszystko nimi zrobic tak, ze sam fakt dodania serwera do konkretnego OU sprawi, ze wszystko, co powinno byc na nim skonfigurowane, zadzieje sie samo. Ale z reka na sercu – kto tak ma w swoim srodowisku? Nie, ze jakies kawalki, przymiarki albo proof of concept, tylko dzialajace, w pelni automatyczne rozwiazanie konfigurujace serwery zgodnie z firmowymi politykami od poczatku do konca? A przeciez mamy swietne narzedzia, mozemy oszczedzic sporo zmudnej pracy i uniknac bledów! Tylko jakos w codziennej praktyce te narzedzia nie sa az tak fantastyczne, skoro nikt nie wyrywa sie do ich stosowania...

Prawdopodobnie do takiego samego wniosku doszedl ktos w Microsoft i zamiast jeszcze mocniej przekonywac "uzywajcie GPO", zaproponowal zupelnie nowe rozwiazanie. Oparte oczywiscie (takie czasy) o PowerShella, przyjazniejsze dla administratora, strawne dla menedzera, zaprojektowane dla serwerów i dajace sie uzyc w starszych wersjach systemu. Mowa o tytulowym Desired State Configuration.

DSC wprowadza nowe podejscie bazujace na prostych tekstowych plikach konfiguracyjnych. Prostych, znaczy latwych do stworzenia, latwych do przerobienia w razie potrzeby i latwych do zrozumienia dla menedzerów. Kazdy z tych aspektów jest w praktyce równie istotny. Plik taki zaczyna sie od slowa "Configuration" i zawiera sekcje odpowiedzialne za poszczególne aspekty konfiguracji. Na przyklad:

Configuration test1
{
WindowsFeature IIS
{
Ensure="Present"
Name="Web-Server"
}
}

Po uruchomieniu takiego skryptu i wpisaniu "test1" otrzymamy plik folder z plikami z rozszerzeniem *.mof. Brzmi znajomo? W skrócie powiedziec mozna, ze jest to tekstowy plik zawierajacy opisana wczesniej konfiguracje w postaci strawnej dla automatycznego przetworzenia.

Samo przetworzenie uruchamia sie cmdletem Start-DscConfiguration, którego parametrem powinna byc lokalizacja folderu z plikami *.mof. Dodanie parametrów -Wait i -Verbose sprawi, ze wszystko ladnie bedzie widac.

Na razie, widac, ze skomplikowalismy sobie skryptowa instalacje ról serwera. Troche wiecej entuzjazmu wzbudzic moze swiadomosc, ze oprócz ról serwera, do dyspozycji mamy calkiem przydatny zestaw parametrów, formalnie zwanych DSC Resources:

• Archive – sluzacy do rozpakowania archiwum w zadanej lokalizacji
• Environment – zarzadzajacy zmiennymi srodowiskowymi
• File – zarzadzajacy plikami i folderami
• Group – zarzadzajacy lokalnymi grupami uzytkowników
• Log – rejestrujacy dzialania DSC w Event Log
• Package – zarzadzajacy instalacja paczek (na przyklad MSI)
• WindowsProcess – zarzadzajacy procesami na serwerze
• Registry – odpowiadajacy za wpisy w rejestrze systemu
• WindowsFeature – pozwalajacy instalowac i usuwac role i funkcjonalnosci serwera
• Script – umozliwiajacy uruchomienie na docelowym serwerze zadanego skryptu
• Service – sluzacy do zarzadzania serwisami systemowymi
• User – zarzadzajacy lokalnymi kontami uzytkowników

Podczas testów, warto przyjrzec sie tym parametrom dokladniej, poniewaz ich mozliwosci sa zwykle dosc rozbudowane. Serwisy systemowe mozna uruchamiac, zatrzymywac, tworzyc czy usuwac, uzytkownikom mozna ustawiac hasla itp. Mozna równiez zdefiniowac wlasne klasy zasobów DSC, jednak na pewno wymaga to na poczatek opanowania standardowych zasobów i na razie temat ten pomine.

Skrypty konfiguracyjne mozna oczywiscie parametryzowac, dostosowujac je do funkcji serwera (na przyklad dodajac parametr, którym decydujemy czy w danym przypadku na serwerze ma byc IIS czy nie) czy zmuszajac do specyficznego dzialania na maszynie o zadanej nazwie.

Jak dotad widac, dzieki DSC mozna nieco uproscic zarzadzanie przez skrypty. Zamiast pisac skrypty sluzace do zarzadzania kazdym z wymienionych wyzej aspektów konfiguracji, mozna uzyc pliku tekstowego z opisem pozadanego stanu i zaaplikowac go na serwerze jednym prostym poleceniem. Jest to jakis krok w dobra strone, glównie dlatego, ze utrzymanie nadazajacej za wymaganiami tresci takiego pliku tekstowego jest prostsze niz utrzymywanie rozwiazan skryptowych. Ponadto, sens dzialania pliku konfiguracyjnego jest zrozumialy dla kogos wiecej niz tylko dla autora. Mozna polemizowac czy lepsze sa takie pliki czy prawdziwe skrypty, jednak jezeli w prawdziwym srodowisku skrypty konfigurujace serwery nie sa szeroko stosowane, to cala dyskusja traci sens. Lepsze bedzie dzialajace DSC niz niedzialajace skrypty.

Piekno DSC nie tkwi jednak wylacznie w uproszczeniu opisu pozadanego stanu. Dzieki PowerShellowi mozemy robic naprawde ciekawe rzeczy:

• Sprawdzic (Test-DscConfiguration), czy biezaca konfiguracja jest zgodna ze zdefiniowanymi regulami (cmdlet zwraca True lub False, ale to wystarczy, zeby administrator wiedzial czy powinien zareagowac czy moze spac spokojnie)
• Zweryfikowac (Get-DscConfiguration), jaki jest biezacy stan parametrów, którymi chcielibysmy zarzadzac. Operacja ta pozwala dowiedziec sie, dlaczego opisany wczesniej Test-DscConfiguration zwrócil False.
• Siegac do komputerów zdalnych i zarzadzac konfiguracja albo poprzez pociagniecie (pull) konfiguracji z centralnego repozytorium, albo poprzez wypchniecie (push) ustawien z lokalnego komputera na nowy serwer.

Konfiguracja typu pull oznacza, ze konfigurowany serwer okresowo (domyslnie co 30 minut) sprawdza czy plik z ustawieniami odpowiada temu, co dzieje sie na serwerze. Moze nadpisywac automatycznie juz istniejacy plik konfiguracyjny, jednak zalezy to od ustawienia przez administratora. Konfiguracja serwera udostepniajacego pliki nie jest trywialna, poniewaz wykorzystuje on specjalna role Windows PowerShell Desired State Configuration.

Mechanizmy DSC (DscLocalConfigurationManager) moga reagowac na rózne sposoby. Domyslnie, (czyli w trybie ApplyAndMonitor), w przypadku wykrycia niezgodnosci, w Event Logu zapisywana jest odpowiednia informacja. Tryb dzialania przelaczyc mozna jednak na ApplyAndAutoCorrect i wtedy niezgodnosci sa automatycznie usuwane.

W efekcie, dostajemy do reki nowy, interesujacy mechanizm, który:

• pozwala prosto zautomatyzowac ustawianie waznych dla nas parametrów serwera
• sam sprawdza czy serwer jest zgodny z pozadanym stanem i madrze reaguje na niezgodnosci
• moze dzialac w sposób scentralizowany, zarzadzajac zdalnymi serwerami

W skrócie: prawie jak GPO ale dla prawdziwych twardzieli.

Jezeli w srodowisku nie ma skutecznego scentralizowanego zarzadzania konfiguracja i jezeli ktokolwiek uwaza, ze jednak nie byloby to zupelnie zbedne – zdecydowanie warto przyjrzec sie blizej Desired State Configuration.

Autor: Grzegorz Tworek [MVP]

Comments

• Anonymous
  January 01, 2003
  Jak zawsze rzeczowo i z jajem. Ciekawa możliwość z wielkim potencjałem.