Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



01.12.2022

Wyższy poziom programowania

Progress oferuje nowe narzędzia programistyczne: Progress Telerik, Progress Kendo UI i...
01.12.2022

Łączność w podróży

VMware SD-WAN VMware zaprezentował rozwiązanie SD-WAN nowej generacji, w tym nowego...
01.12.2022

Bezpieczne e-maile

Nowa aplikacja firmy Cypherdog Security Inc. umożliwia bezpieczną wymianę maili i...
01.12.2022

Pierwszy w branży

Schneider Electric wprowadza na rynek APC Smart-UPS Ultra. To pierwszy w branży...
01.12.2022

Przełączniki 10G dla MŚP

Nowe urządzenia to przełączniki 10G kompatybilne z systemem Omada SDN.
01.12.2022

Zarządzanie danymi

Firma Synology wprowadziła na rynek czterokieszeniowy DiskStation DS923+.
01.12.2022

Nowatorski system chłodzenia

OVHcloud zaprezentował nową, autorską technologię hybrydowego zanurzeniowego chłodzenia...
01.12.2022

Linia smart routerów

D-Link zaprezentował najnowszą rodzinę routerów Smart Wi-Fi z algorytmami sztucznej...
04.11.2022

Nowa platforma Red Hat

Nowa platforma Red Hat Enterprise Linux (RHEL) w wersjach 8.7 i 9.1 Beta obsługuje...

PowerShell Universal – zastosowania praktyczne

Data publikacji: 04-01-2022 Autor: Bartosz Bielawski

PowerShell Universal to platforma, dzięki której możemy tworzyć kompletne narzędzia zarówno dla administratorów przyzwyczajonych do korzystania z narzędzi GUI, użytkowników preferujących komunikowanie się z API, jak i osób piastujących stanowiska kierownicze. W ostatniej części cyklu o PowerShell Universal przyjrzymy się kilku praktycznym zastosowaniom, dzięki którym platforma pozwoli rozwiązać faktyczne problemy wewnątrz organizacji.

 

Podobnie jak to miało miejsce w przypadku omawiania poszczególnych elementów PSU, postaramy się przyjrzeć po kolei każdemu z elementów platformy i temu, gdzie znalazły one zastosowanie. Zwykle bowiem każdy z napotkanych problemów został rozwiązany za pomocą wyłącznie jednego elementu narzędzia. Tam, gdzie to możliwe, postaramy się jednak przybliżyć, jak mogłoby wyglądać analogiczne rozwiązanie wykorzystujące pozostałe elementy. Jeśli więc praktyczne rozwiązanie w naszym wypadku ograniczyło się do Universal API, to postaramy się nakreślić, jak mogłoby ono wyglądać, gdybyśmy skorzystali z Universal Dashboard bądź Universal Automation.


> GRUPY ROZWIĄZAŃ


Universal API najlepiej sprawdzi się wszędzie tam, gdzie musimy umożliwić dostęp do zasobów na co dzień obsługiwanych za pomocą poleceń PowerShella dla urządzeń i użytkowników, którzy z PowerShella z różnych powodów nie korzystają. Faktem jest to, że dziś PowerShella zainstalować można niemal wszędzie, ale nie oznacza to wcale, że w firmie, gdzie pracuje się równolegle na Linuksie i Windowsie, faktycznie dostęp będziemy mieli do niego wszędzie. Co równie ważne, sam fakt zainstalowania PowerShella nie oznacza natychmiast dostępu do wszystkich narzędzi. PowerShell remoting za pomocą WinRM wymaga sporo dodatkowej pracy, a jego wymogi mogą nie zostać zaakceptowane przez administratorów systemu. W takiej sytuacji możliwość zaoferowania REST API może być świetnym sposobem na zasypanie przepaści dzielącej oba systemy i stworzenie środowiska, gdzie tego rodzaju bariery przestają istnieć.


Druga grupa rozwiązań, która może wykorzystywać Universal API, to wszelkiego rodzaju systemy, które oferują komunikację z zewnętrznym światem za pomocą tzw. webhooks. W tym wypadku możemy przygotować końcówkę, która takie odwołania obsłuży, i nieco odwrócić kierunek, czyniąc z systemu Windows „odbiorcę”, a z systemów oferujących tego rodzaju rozwiązania – nadawcę.


Ostatnia grupa to rozwiązania stosowane, gdy zależy nam na ustandaryzowaniu procesów w przedsiębiorstwie. Dzięki wykorzystaniu API możemy bowiem wprowadzić walidację. Możemy izolować pewne środowiska, zapewniając dostęp do pewnych segmentów sieci jedynie tym serwerom, na których działa API. Wreszcie możemy modyfikować parametry tak, by wynik poleceń był przewidywalny, np. zadbać o to, by nazwy serwerów w DNS były zawsze tworzone z użyciem wyłącznie małych liter.


> BOGACTWO NARZĘDZI


W przykładowej firmie za pomocą PowerShell Universal rozwiążemy w ten sposób kilka problemów. Przede wszystkim zależy nam na ułatwieniu modyfikowania ustawień DNS, które przechowywane są w Active Directory. Chodzi tu zarówno o umożliwienie niewielkich, konkretnych zmian (tworzenie, modyfikowanie i usuwanie wpisów typu A, CName oraz PTR), jak i zmian bardziej złożonych, jak przenoszenie CName pomiędzy dwoma serwerami po uprzednim upewnieniu się, że zarówno źródło, jak i cel spełniają wymagane przez nas kryteria. Oprócz tego postanowiliśmy udostępnić informacje, które co prawda można zgromadzić, wykonując wiele pojedynczych zapytań, ale są trudne do sprawdzenia w jednym zapytaniu, np. lista wpisów CName wskazujących na konkretne urządzenie w naszej organizacji. W przypadku tego API duże znaczenie ma również ograniczenie dostępu do DNS dla kont używanych na co dzień, niewymagających uprawnień do tworzenia nowych domen czy modyfikowania parametrów serwera DNS. Nie bez znaczenia była też możliwość standaryzacji tworzonych wpisów na DNS.


Ponadto chcielibyśmy ułatwić kontrolowanie agentów systemu Commvault, odpowiedzialnych w naszej firmie za kopie bezpieczeństwa na serwerach Windows i Linux. Tu założenia są nieco prostsze: ważne jest pobranie informacji o zainstalowanym agencie, gdyż agent taki instalowany jest jedynie na wybranych serwerach, a także jego usunięcie, najczęściej na koniec życia serwera, choć bywały i scenariusze, w których serwer tracił rolę wymagającą tworzenia kopii zapasowej.


Trzeci problem, który możemy rozwiązać, związany jest z konfigurowaniem serwerów z użyciem rozwiązań takich jak iLO, ale przede wszystkim iDRAC. Początkowa konfiguracja użytkowników obejmuje ustawienia iDRAC oraz parametry w BIOS-ie za pomocą uprzednio przygotowanych profili – różnych dla Windowsów, Linuksów i hostów ESXi.

 

> PROBLEMY I ZASTOSOWANIA


Jeśli chodzi o rozwiązania, gdzie to Windows stanowić miał „odbiorcę”, to ograniczyliśmy się do dwóch zastosowań. Po pierwsze, postanowiliśmy zintegrować wykorzystywane w naszej firmie narzędzie do CI/CD: Bamboo Server firmy Atlassian z wykorzystywanym przez nasz zespół serwerem SCOM. Rozwiązanie sprowadzało się do wykorzystania wspomnianych uprzednio webhooks.


Drugi problem, który musieliśmy rozwiązać, wynikał z budowanego przez naszych kolegów odpowiedzialnych za instancje linuksowe narzędzia do definiowania naszych intencji i kontrolowania zgodności stanu faktycznego z intencjami. System kontrolujący przesyła każdego dnia wiele zapytań do Universal API, które następnie asynchronicznie przekształcane są w zlecone zadania. Ostatecznie informacja zwrotna (również z wykorzystaniem protokołu REST) wraca do serwera odpowiedzialnego za porównywanie intencji ze stanem faktycznym. Tam też dochodzi do porównania i wygenerowania alarmu, jeśli stan faktyczny nie pokrywa się z naszymi intencjami.


Oczywiście biorąc pod uwagę zakres rozwiązań, musieliśmy zadbać o możliwość uwierzytelniania i autoryzacji użytkowników. Z tego powodu zdecydowaliśmy się na komercyjną licencję PowerShell Universal dla końcówek REST. Część końcówek oferuje dostęp do informacji wymogu uwierzytelniania: było to konieczne z dwu powodów. Przede wszystkim nie wszystkie narzędzia oferowały możliwość przesyłania poświadczeń we wspierany sposób (staraliśmy się skupić na wykorzystaniu do tego celu uwierzytelniania za pomocą kerberos). W innych wypadkach, np. wspomnianego uprzednio zapytania dotyczącego konfiguracji DNS, uwierzytelnianie wydawało się niepotrzebne – ta sama informacja jest dostępna bez tej konieczności dla użytkownika korzystającego z polecenia nslookup bądź dig. Ponieważ nasze rozwiązanie miało jedynie ułatwić dostęp do informacji, dodatkowe komplikowanie sprawy wymogiem uwierzytelniania sprawiłoby, że zamiast ułatwić uzyskiwanie informacji, moglibyśmy niepotrzebnie go skomplikować.

 

Aby zapewnić sobie elastyczność oraz najlepiej wykorzystać możliwości oferowane przez serwery Windows, oparliśmy budowę naszych serwerów PowerShell Universal na serwerze IIS. Do konfiguracji wykorzystujemy PowerShell DSC. Dzięki temu wszelkie zmiany łatwo zastosować na wielu serwerach jednocześnie. Uwierzytelnianie oparte jest na wspomnianym kerberosie, dzięki czemu na systemach Windows możemy swobodnie korzystać ze zintegrowanego uwierzytelniania. Cały mechanizm uwierzytelniania bazuje na członkostwie w grupach Active Directory, które zostały przygotowane specjalnie w tym celu. Grupy te oczywiście zawierają podgrupy, dzięki czemu nie musimy rezygnować ze stosowania dobrych praktyk przy zarządzaniu uwierzytelnianiem w Active Directory. W ten stosunkowo prosty sposób tworzyć możemy końcówki, które wymagać będą jedynie uwierzytelnienia (dostępne dla wszystkich, ale nie anonimowo). Możemy też utworzyć końcówki oferowane jedynie ograniczonej liczbie użytkowników, w tym użytkowników wykorzystywanych przez różnego rodzaju serwisy. Wreszcie część końcówek działać będzie bez jakichkolwiek poświadczeń.


> PRAKTYKA PRACY Z PSU


Zobrazujmy to na przykładach. W DNS ograniczyliśmy się do czynności, które nie wymagają w ogóle uwierzytelniania: pobieranie informacji o wpisach A, CName, PTR, liście wpisów w ramach domeny czy liście wpisów dla wybranego serwera:


New-PSUEndpoint -Url /dns/cnameListZone -Endpoint {
param (
[Parameter()]
[String]$Zone = 'contoso.com',
[String]$Identity
)
try {
$cnames = Get-PSUCache -Key cnameCache
} catch {
New-PSUApiResponse -StatusCode 500 -Body "Exception: $_"
}
$cnamesList = $cnames[$Zone].ForEach{
[PSCustomObject]@{
Name = "$($_.HostName).$Zone"
Target = $_.RecordData.HostNameAlias -replace '.$'
}
}
$cnamesHash = $cnamesList | Group-Object -Property Target -AsHashTable
$cnamesHash.Keys.ForEach{
@{
target = $_
cnames = @($cnamesHash[$_].Name)
}
} | ConvertTo-JsonEx
} -ErrorAction Stop
New-PSUEndpoint -Url /dns/cnameListHost/:fqdn -Endpoint {
param (
[Parameter(Mandatory)]
[String]$FQDN,
[String]$Identity
)
try {
$cnames = Get-PSUCache -Key cnameCache
} catch {
New-PSUApiResponse -StatusCode 500 -Body "Exception: $_"
}
@(foreach ($zone in 'contoso.com', 'comp.contoso.com') {
$cnames[$zone].ForEach{
if (($_.RecordData.HostNameAlias -replace '.$') -eq $FQDN) {
"$($_.HostName).$zone"
}
}
}) | ConvertTo-JsonEx -AsArray
} -ErrorAction Stop
New-PSUEndpoint -Url /dns/serverdnsconfig/:computername -Endpoint {
param (
[Parameter(Mandatory)]
[String]$ComputerName
)
$invokeDnsApiEndpointSplat = @{
ComputerName = '.'
ConfigurationName = 'DnsApi'
ArgumentList = @(
$ComputerName
)
ErrorAction = 'Stop'
}
try {
Invoke-Command @invokeDnsApiEndpointSplat -ScriptBlock {
Get-OPServerDnsConfiguration -ComputerName $args[0]
} | ConvertTo-JsonEx -AsArray
} catch {
New-PSUApiResponse -StatusCode 500 -Body "Exception: $_"
}
} -ErrorAction Stop
New-PSUEndpoint -Url /dns/ptr/:ipaddress -Endpoint {
param (
[Parameter(Mandatory)]
[String]$IPAddress,
[String]$Identity
)
$tokens = $IPAddress.Split('.')
$zone = '{1}.{0}.in-addr.arpa' -f $tokens
$name = '{3}.{2}' -f $tokens
$invokeDnsApiEndpointSplat = @{
ComputerName = '.'
ConfigurationName = 'DnsApi'
ArgumentList = @(
$name
$zone
)
ErrorAction = 'Stop'
}
try {
Invoke-Command @invokeDnsApiEndpointSplat -ScriptBlock {
Get-OPDnsRecord -Name $args[0] -Zone $args[1] -Type PTR `
-UseLinuxPrimary
} | ForEach-Object {
@{
HostName = $_.HostName
PtrDomainName = $_.RecordData.PtrDomainName
TimeToLive = "$($_.TimeToLive)"
Zone = $zone
}
} | ConvertTo-JsonEx -AsArray
} catch {
New-PSUApiResponse -StatusCode 500 -Body "Exception: $_"
}
} -ErrorAction Stop

 

 

[...]

 

Autor zawodowo zajmuje się informatyką. Jest Microsoft MVP w dziedzinie PowerShella, blogerem oraz jednym z moderatorów forum dotyczącego skryptów w serwisie TechNet. Autor książki „Windows PowerShell 5.1 Biblia”.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik \"IT Professional\"