Omówienie platformy Desired State Configuration dla inżynierów

Ten dokument jest przeznaczony dla zespołów deweloperów i operacji, aby zrozumieć zalety programu PowerShell Desired State Configuration (DSC). Aby uzyskać wyższy poziom widoku wartości DSC, zobacz Desired State Configuration Omówienie dla osób podejmujących decyzje

Zalety Desired State Configuration

DsC istnieje do:

• Zmniejszanie złożoności skryptów w systemie Windows
• Zwiększanie szybkości iteracji

Koncepcja "ciągłego wdrażania" staje się coraz ważniejsza. Ciągłe wdrażanie oznacza możliwość częstego wdrażania, potencjalnie wiele razy dziennie. Celem tych wdrożeń nie jest naprawienie czegoś, ale szybkie opublikowanie czegoś. Dzięki uzyskaniu nowych funkcji dzięki programowi deweloperskiemu można jak najbardziej bezproblemowo i niezawodnie skrócić czas na wartość nowej logiki biznesowej.

Przejście do przetwarzania w chmurze oznacza rozwiązanie wdrożeniowe korzystające z modelu szablonu "deklaratywnego", w którym środowisko stanu końcowego jest deklarowane jako tekst i opublikowane w aplikatorze wdrażania. Ta technika wdrażania umożliwia szybkie zmiany na dużą skalę z odpornością na zagrożenie awarią, ponieważ w dowolnym momencie wdrożenie może być stale powtarzane w celu zagwarantowania stanu końcowego. Tworzenie narzędzi i usług, które obsługują ten styl operacji za pośrednictwem automatyzacji, jest odpowiedzią na te zmiany.

DSC to platforma, która zapewnia deklaratywne i idempotentne (powtarzalne) wdrożenie, konfigurację i zgodność. Platforma DSC umożliwia zapewnienie, że składniki centrum danych mają poprawną konfigurację, co pozwala uniknąć błędów i zapobiega kosztownym awariom wdrażania. Traktując konfiguracje DSC w ramach kodu aplikacji, DSC umożliwia ciągłe wdrażanie. Konfiguracja DSC powinna zostać zaktualizowana w ramach aplikacji, zapewniając, że wiedza wymagana do wdrożenia aplikacji jest zawsze aktualna i gotowa do użycia.

"Mam program PowerShell, dlaczego potrzebuję Desired State Configuration?"

Konfiguracje DSC oddzielają intencję lub "to, co chcę zrobić", od wykonania lub "jak chcę to zrobić". Oznacza to, że logika wykonywania jest zawarta w zasobach. Użytkownicy nie muszą wiedzieć, jak zaimplementować lub wdrożyć funkcję, gdy jest dostępny zasób DSC dla tej funkcji. Dzięki temu użytkownik może skupić się na strukturze wdrożenia.

Na przykład skrypty programu PowerShell powinny wyglądać następująco:

# Create a share in Windows Server 8
New-SmbShare -Name MyShare -Path C:\Demo\Temp -FullAccess Alice -ReadAccess Bob

Ten skrypt jest prosty, zrozumiały i prosty. Jeśli jednak spróbujesz umieścić ten skrypt w środowisku produkcyjnym, wystąpi kilka problemów. Co się stanie, jeśli ten skrypt jest uruchamiany dwa razy z rzędu? Co się stanie, jeśli Bob miał wcześniej pełny dostęp do udziału?

Aby zrekompensować te problemy, "prawdziwa" wersja skryptu będzie wyglądać bliżej czegoś podobnego:

# But actually creating a share in an idempotent way would be

$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
    Write-Verbose -Message "Share with name $Name exists"
    $shareExists = $true
}

if ($shareExists -eq $false)
{
    Write-Verbose "Creating share $Name to ensure it is Present"
    New-SmbShare @PSBoundParameters
}
else
{
    # Need to call either Set-SmbShare or *ShareAccess cmdlets
    if ($PSBoundParameters.ContainsKey("ChangeAccess"))
    {
       #...etc, etc, etc
    }
}

Ten skrypt jest bardziej złożony, z dużą ilością logiki i obsługi błędów. Skrypt jest bardziej złożony, ponieważ nie stwierdzasz już, co chcesz zrobić, ale jak to zrobić.

DsC pozwala powiedzieć, co chcesz zrobić, a podstawowa logika jest abstrakcja.

# A configuration is a special kind of PowerShell function
Configuration Sample_Share
{
   Import-DSCResource -ModuleName xSmbShare
   # Nodes are the endpoint we wish to configure
   # A Configuration block can have zero or more Node blocks
   Node $NodeName
   {
      # Next, specify one or more resource blocks
      # Resources are simply PowerShell modules that
      # implement the logic of "how" to execute a task
      xSmbShare MySMBShare
      {
          Ensure      = "Present"
          Name        = "MyShare"
          Path        = "C:\Demo\Temp"
          ReadAccess  = "Bob"
          FullAccess  = "Alice"
          Description = "This is an updated description for this share"
      }
   }
}
#Run the function to compile the configuration
Sample_Share
#Pass the configuration to the nodes we defined and configure them
Start-DscConfiguration Sample_Share

Ten skrypt jest czytelnie sformatowany i prosty do odczytania. Ścieżki logiki i obsługa błędów są nadal obecne w implementacji zasobu , ale niewidoczne dla autora skryptu.

Oddzielenie środowiska od struktury

Typowym wzorcem w usłudze DevOps jest posiadanie wielu środowisk do wdrożenia. Na przykład może istnieć środowisko "dev" używane do szybkiego tworzenia prototypów nowego kodu. Kod ze środowiska "dev" przechodzi do środowiska "testowego", w którym inne osoby weryfikują nowe funkcje. Na koniec kod przechodzi do środowiska produkcyjnego "prod" lub środowiska produkcyjnego lokacji na żywo.

Konfiguracje DSC umożliwiają korzystanie z tych potoków dev-test-prod przy użyciu danych konfiguracji. W ten sposób opisano różnicę między strukturą konfiguracji z zarządzanych węzłów. Można na przykład zdefiniować konfigurację, która wymaga serwera SQL, serwera USŁUG IIS i serwera warstwy środkowej. Niezależnie od tego, jakie węzły otrzymują różne elementy tej konfiguracji, te trzy elementy będą zawsze obecne. Możesz użyć danych konfiguracji, aby wskazać wszystkie trzy elementy w kierunku tej samej maszyny dla środowiska deweloperskiego, rozdzielić trzy elementy na trzy różne maszyny dla środowiska testowego, a na koniec do wszystkich serwerów produkcyjnych dla środowiska prod. Aby wdrożyć w różnych środowiskach, możesz wywołać Start-DscConfiguration odpowiednie dane konfiguracji dla środowiska, które chcesz kierować.

Zobacz też

Konfiguracje

Dane konfiguracji

Zasoby