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



29.12.2022

Nowe funkcje od Oracle

W aplikacjach CX, SCM, EPM i HCM Fusion Cloud firmy Oracle pojawiło się wiele nowych...
29.12.2022

Inteligentne sygnały

Nowa usługa Vectra MDR zapewnia wsparcie ekspertów w zakresie bezpieczeństwa...
29.12.2022

Wieloetapowa analiza treści

Firma WithSecure wprowadziła nową warstwę ochrony w swojej opartej na chmurze platformie...
29.12.2022

Kontrola aplikacji

Fortinet zaprezentował nowe funkcje systemu FortiSASE: bezpieczny prywatny dostęp (Secure...
29.12.2022

Zgodnie z przepisami

Nowe rozwiązanie do zarządzania danymi firmy Commvault, oferowane w formie usługi,...
29.12.2022

Większa elastyczność w...

Schneider Electric ogłosił wprowadzenie na rynek urządzenia zasilającego APC NetShelter...
29.12.2022

Firewall nowej generacji

Fortinet zaprezentował nową rodzinę zapór sieciowych nowej generacji (NGFW) – FortiGate...
29.12.2022

Nowy przełącznik źródeł...

Vertiv przedstawił nową rodzinę przełączników źródeł zasilania Vertiv Geist RTS, które...
29.12.2022

Routery VPN Omada

TP-Link poszerza portfolio routerów VPN o dwa nowe urządzenia. ER7212PC to urządzenie 3 w...

Profesjonalne wytwarzanie skryptów

Data publikacji: 29-12-2022 Autor: Michał Gajda

Skryptowa automatyzacja może nie jest tak skomplikowanym procesem deweloperskim jak pisanie aplikacji, niemniej jednak możemy w tym celu wykorzystywać te same specjalistyczne narzędzia. Dzięki nim nawet tak proste rozwiązania jak skrypty Windows PowerShell mogą być wytwarzane w profesjonalny sposób.

 

W zarządzaniu infrastrukturą IT automatyzacja zadań pozwala na ustandaryzowanie przeprowadzanych prac oraz znaczne skrócenie czasu wykonywanych operacji. W środowisku systemów Windows, ale i nie tylko, jako podstawowe narzędzie do automatyzacji przyjęło się używać skryptowego języka, jakim jest Windows PowerShell.


Wspomniane skrypty PowerShella dają nam praktycznie nieograniczone możliwości kreowania własnej infrastruktury. Jednak im więcej mamy skryptów, tym trudniej nimi zarządzać. W szczególności gdy niektóre z rozwiązań mogą ciągle ewoluować, np. poprzez optymalizację kodu czy po prostu implementowanie nowych funkcjonalności. By móc łatwo odnaleźć się w omawianym środowisku skryptowym, konieczne jest wdrożenie centralnego repozytorium kodu, z poziomu którego będą przeprowadzane wszelakie zmiany deweloperskie. Dodatkowo konieczne jest zastosowanie centralnego rozwiązania do dystrybucji skryptów, tak by mogły być w łatwy sposób zaimplementowane w ramach docelowych serwerów końcowych. Takim centralnym rozwiązaniem do dystrybucji skryptów może być usługa Azure DevOps.


> AZURE DEVOPS


Usługa Azure DevOps jest narzędziem wykorzystywanym do nowoczesnego zarządzania procesami deweloperskimi. Przeznaczona jest głównie do wykorzystywania podczas tworzenia aplikacji, niemniej jednak może być również skutecznie zastosowana w mniejszej skali, np. do zarządzania własnymi skryptami. Usługa dostarcza szereg komponentów, m.in. repozytorium kodu źródłowego Git, automatyzację procesów przy wykorzystaniu Azure Pipelines czy dedykowaną przestrzeń do hostowania pakietów przeznaczonych do dalszej dystrybucji.


Przewagą wspomnianego narzędzia jest jego dostępność. Całe rozwiązanie jest zlokalizowane w chmurze usług Microsoft, dzięki czemu nie musimy implementować żadnych dodatkowych elementów wewnątrz lokalnej infrastruktury organizacji. Dodatkowo w przypadku niewielkich rozwiązań nieprzekraczających 2 GB oraz skupiających maksymalnie pięciu deweloperów z całego środowiska możemy korzystać zupełnie bez ponoszenia dodatkowych kosztów.


Aby wykreować nowe środowisko Azure DevOps, należy przejść do witryny usługi i skorzystać z opcji Rozpocznij bezpłatnie. Ostatecznie wystarczy zalogować się do usługi za pomocą służbowego lub osobistego konta Microsoftu w celu wykreowania nowej organizacji. W ramach wspomnianej organizacji usługi Azure DevOps będziemy mogli tworzyć projekty do zarządzania swoimi rozwiązaniami skryptowymi.


> ARTEFAKTY


Każdy projekt usługi Azure DevOps ma zdefiniowany zestaw komponentów do organizacji pracy deweloperskiej. Jednym z nich są artefakty (Azure Artifacts). Pozwalają one na udostępnianie pakietów, wśród których mogą znajdować się m.in. paczki typu NuGet. W przypadku omawianej prywatnej galerii skryptów jest to idealne narzędzie do centralnego składowania gotowych do dystrybucji skryptów PowerShella. Analogiczny mechanizm paczek NuGet jest również stosowany w ramach oficjalnej galerii skryptów, jaką jest PowerShell Gallery.


Domyślnie każda organizacja ma automatycznie wdrożony jeden kanał artefaktów (Artifacts Feed). Jednakże jeżeli potrzebujemy ich więcej, możemy utworzyć własne dedykowane kanały. Jest to szczególnie przydatne, gdy zamierzamy rozdzielić poszczególne skrypty, tak by konkretne rozwiązania były od siebie odseparowane, a co za tym idzie, nie były dostępne w ramach jednego docelowego repozytorium skryptów Windows PowerShell podmapowanego na końcowych serwerach. Proces tworzenia kanału artefaktów nie jest skomplikowany i został pokrótce przybliżony w ramce Krok po kroku: Tworzenie kanału artefaktów.


> PUBLIKOWANIE SKRYPTÓW


Gdy mamy już gotowy kanał artefaktów, możemy przejść do stworzenia serca całego mechanizmu, czyli centralnego repozytorium kodu źródłowego dla naszych skryptów. W tym celu wykorzystamy komponent Repos – Files usługi Azure DevOps. W jego ramach mamy do dyspozycji m.in. repozytorium Git, gdzie możemy przechowywać kod źródłowy naszych skryptów.


Przy wykorzystaniu dogodnego dla nas narzędzia deweloperskiego, np. Visual Studio Code, możemy edytować kod i docelowo synchronizować go z repozytorium w chmurze (rys. 2). Oczywiście samo zapisanie kodu źródłowego w chmurowej usłudze nie zapewni na razie automatycznego opublikowania skryptu w naszej prywatnej galerii. By było to możliwe, musimy zbudować odpowiedni przepływ. Wykorzystamy do tego komponent Azure Pipelines. W naszym testowym przypadku skupimy się na najprostszej możliwej formie przepływu, która będzie tylko budowała paczkę NuGet i ostatecznie publikowała ją w ramach wcześniej utworzonego kanału artefaktów. Zanim przejdziemy do utworzenia przepływu, musimy przygotować kilka dodatkowych elementów. Jednym z nich będzie plik manifestu przygotowywanej paczki NuGet. W tym celu w naszym repozytorium tworzymy plik z rozszerzeniem .nuspec, w którym zapisujemy przykładowy kod XML manifestu:


<?xml version=”1.0”?>
<package>
       <metadata>
               <id>$ID$</id>
               <version>$VERSIONHERE$</version>
               <authors>$AUTHORS$</authors>
               <requireLicenseAcceptance>false
</requireLicenseAcceptance>
               <description>$DESCRIPTION$
</description>
               <copyright>$COPYRIGHT$</copyright>
       </metadata>
       <files>
               <file src=”PSScripts**”/>
       </files>
</package>


Aby rozwiązanie było bardziej uniwersalne, dynamiczną zawartość manifestu możemy zdefiniować za pomocą zmiennych (np.: identyfikator, wersja, opis publikowanej paczki NuGet, autor czy informacje o prawach autorskich). Każda z nich musi być zdefiniowana w charakterystyczny sposób za pomocą znaku $. Docelowo pod każdą zmienną będą dynamicznie podstawiane dane podczas uruchamiania przepływu Azure Pipeline.


Następnie przechodzimy do drugiej kwestii, czyli zdefiniowania manifestu przepływu Azure Pipeline. Podobnie jak w przypadku manifestu paczki NuGet, tak i tutaj w ramach repozytorium tworzymy dedykowany plik, jednakże tym razem z rozszerzeniem .yml. Jako zawartość pliku azure-pipelines.yml deklarujemy kod YAML, który będzie zawierał cechy kluczowych sekcji naszego przepływu. W ramach przepływu będą definiowane następujące elementy:

 

  • Trigger – zdefiniowanie formy wyzwalania przepływu, np. ręcznie (none) lub automatycznie po zatwierdzeniu nowych plików źródłowych w głównej gałęzi repozytorium (main);
  • Variables – zmienne wykorzystywane w tworzonym przepływie. W tych elementach będą statycznie zdefiniowane wcześniej wspomniane parametry manifestu paczki NuGet. Mogą być definiowane na kilka sposobów, np. klasycznie w ramach poszczególnych wpisów w manifeście. Mogą być również zdefiniowane za pomocą dedykowanych grup zmiennych (Variable Groups) deklarowanych w ramach biblioteki (Library) projektu.
  • Pool – określenie puli agentów, w ramach której będzie uruchamiany przepływ. Ze względu na to, że natywnym środowiskiem skryptów PowerShell są systemy z rodziny Windows, w naszym testowym przypadku wykorzystamy pulę agentów windows-latest;
  • Stages/Jobs – docelowe etapy i zadania wykonywane w ramach przepływu. W naszym przypadku będą to dwie komendy narzędzia NuGet, czyli Pack oraz Push.

 

[...]

 

Autor ma wieloletnie doświadczenie w administracji oraz implementowaniu nowych technologii w infrastrukturze serwerowej. Pasjonat technologii Microsoft. Posiada tytuł MVP Cloud and Datacenter Management.

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\"