Profesjonalna praca ze skryptami Windows PowerShell nie musi kończyć się na etapie wytwarzania kodu źródłowego. Wykorzystanie odpowiednich narzędzi pozwala również na fachowe dostarczanie wyprodukowanych automatyzacji środowisku IT.

Usługa Azure DevOps idealnie sprawdza się jako narzędzie do zarządzania kodem, dlatego może być z powodzeniem wykorzystywana przez deweloperów aplikacji. Równie skutecznie mogą się nią jednak posługiwać administratorzy chcący profesjonalnie zarządzać swoimi skryptami do automatyzacji zadań. W szczególności gdy są to skrypty Windows PowerShell, które stanowią niezaprzeczalny standard w środowisku systemów Windows.

W poprzedniej części artykułu przedstawiliśmy metodologię wytwarzania skryptów przy wykorzystaniu chmurowej usługi Azure DevOps. Dzięki niej oprócz zarządzania kodem źródłowym mogliśmy przygotować swoją własną, prywatną galerię skryptów Windows PowerShell. W niniejszym artykule skupimy się na praktycznym podejściu ciągłości dostarczania, czyli jak zautomatyzować dystrybucję skryptów do docelowych systemów w naszej wewnętrznej infrastrukturze.

> Automatyzacja zadań

Automatyzacja pracy w usłudze Azure DevOps odbywa się za pośrednictwem przepływów Azure Pipeline. W ramach usługi możemy rozróżnić kilka ich typów. Pierwszym z nich jest przepływ kompilacji (ang. build pipeline), czyli przepływ zaprezentowany w artykule opisującym przygotowywanie skryptów. Odpowiadał on za przygotowywanie kodu źródłowego skryptu i publikowanie go w formie paczek NuGet w ramach prywatnej galerii skryptów.

Drugim wartym uwagi rodzajem przepływów są przepływy wydania (ang. release pipeline). Dzięki nim możemy zautomatyzować proces wydawania oprogramowania. W naszym prezentowanym przypadku zamiast na oprogramowaniu operujemy na skryptach Windows PowerShell, automatyzujących zadania administracyjne. Dlatego nasze przepływy wydania będą skupiać się na dystrybucji poszczególnych skryptów w ramach odpowiednich maszyn końcowych.

Domyślnie obydwa rodzaje przepływów narzędzia Azure DevOps są uruchamiane w ramach skonteneryzowanego środowiska w chmurze. Dotyczy to zarówno środowisk dla systemu Windows, jak i Linux. Niestety owe podejście nie jest przydatne, gdy zamierzamy dotykać na przykład elementów lokalnej infrastruktury serwerowej. W przypadku integracji wykonywania zadań w ramach lokalnego środowiska konieczne jest wdrożenie dodatkowego elementu w całym rozwiązaniu.

> Deployment groups

Wykonywanie zadań w ramach lokalnej infrastruktury IT wymaga zainstalowania dedykowanych agentów na poszczególnych maszynach końcowych. Aby tego dokonać, konieczne jest najpierw zdefiniowanie odpowiednich grup wdrażania (ang. deployment group). Dzięki nim możliwe jest logiczne pogrupowanie lokalnych serwerów, np. na podstawie ich systemu czy przeznaczenia, na których będziemy wykonywali poszczególne akcje. Analogicznie jak dla domyślnych pul agentów chmurowych, tak i dla agentów grup wdrażania możliwe jest stosowanie zarówno systemów z rodziny Windows, jak i Linux. Cała procedura różni się jedynie zastosowaniem innego skryptu instalacyjnego dla docelowego systemu. Przykładowa procedura tworzenia grup wdrażania została przybliżona w ramce Krok po kroku: Tworzenie grupy wdrażania.

Utworzenie pustej grupy wdrażania jest dopiero pierwszym krokiem w całej procedurze. Kluczowym elementem każdej grupy wdrażania jest odpowiednie jej zasilenie końcowymi serwerami z naszej infrastruktury. Żeby to zrobić, wystarczy w ramach poszczególnych serwerów uruchomić wcześniej skopiowany skrypt. Proces instalacji agenta jest maksymalnie zautomatyzowany i w zależności od wybranej ścieżki wymaga od administratora podania tylko kilku podstawowych informacji, jak np. tagi. Pozwalają one na opisanie serwera dodatkowymi metadanymi, które mogą być później wykorzystywane podczas filtrowania uruchamianych akcji. Oczywiście tagi mogą być również zdefiniowane w późniejszym terminie z poziomu konsoli zarzadzania grupą wdrażania, dlatego nie musimy się nimi przejmować, jeżeli na tym etapie nie mamy jeszcze pomysłu na ich zastosowanie. Dodatkowo możemy również określić konto, w ramach którego będzie pracował agent – domyślnie będzie to konto NT AUTHORITYSYSTEM – oraz czy usługa agenta ma być uruchomiona automatycznie po zakończeniu instalacji.

[...]

Autor ma wieloletnie doświadczenie w administracji oraz implementowaniu nowych technologii w infrastrukturze serwerowej. Pasjonat technologii Microsoft. Posiada tytuł MVP Cloud and Datacenter Management. Autor webcastów, książek oraz publikacji w czasopismach i serwisach branżowych.