Zasoby i środowiska w Azure DevOps

Bazując na dokumentacji MS, środowiska (environments) są logicznymi kontenerami, które grupują zasoby. Zasoby, w tym kontekście, tak na prawdę oznaczają systemy, na których możliwe jest wykonanie wdrożenia aplikacji (deployment targets). Typowo definiuje się środowiska Dev, Test, Production itp., jednak logika jest tu dowolna.

Posiadając zdefiniowaną strukturę środowisk i poszczególnych zasobów, można ich używać w Pipeline (zarówno jednych jak i drugich) do wykonania jakiś operacji na systemach docelowo hostujących nasze aplikacje. Dodatkowo środowiska pozwalają na śledzenie historii wdrożeń wraz z informacją o commitach, na podstawie których dokonano konkretnego wdrożenia. Dokumentacja wskazuje również aspekty związane z diagnostyką i bezpieczeństwem.

W momencie pisania tego tekstu, Azure DevOps wspiera dwa typy zasobów – Kubernetes i Maszyny wirtualne. Te drugie (mimo swojej nazwy) to tak na prawdę dowolne systemy operacyjne, na których jesteśmy w stanie zainstalować oprogramowanie agenta. Właśnie instalacji agenta i przykładowej konfiguracji Pipeline chcę poświęcić ten wpis.

Samego procesu tworzenia środowiska nie będę pokazywał, bo ogranicza się to do przeklikania ścieżki Pipelines -> Environments -> New Environment. Ciekawiej robi się na etapie dodawania zasobu typu „maszyna wirtualna”, bo tam MS mocno nie dopracował GUI ;-).

Problematyczny okazuje się krok pierwszy, w którym trafimy na kilka niedomówień.

Przede wszystkim widzimy tu skrypt, którego tak na prawdę nie widzimy i który czasami nie chce się skopiować po kliknięciu w ikonkę ;-). Wygląda on jak niżej.

mkdir azagent;
cd azagent;
curl -fkSL -o vstsagent.tar.gz https://vstsagentpackage.azureedge.net/agent/3.225.0/vsts-agent-linux-x64-3.225.0.tar.gz;
tar -zxvf vstsagent.tar.gz; 

if [ -x "$(command -v systemctl)" ]; then 

./config.sh --environment --environmentname "test" --acceptteeeula --agent $HOSTNAME --url https://dev.azure.com/pawelworwag/ --work _work --projectname 'DailyRoutine' --auth PAT --token <TOKEN> --runasservice; 
sudo ./svc.sh install; 
sudo ./svc.sh start; 

else 

./config.sh --environment --environmentname "test" --acceptteeeula --agent $HOSTNAME --url https://dev.azure.com/pawelworwag/ --work _work --projectname 'DailyRoutine' --auth PAT --token <TOKEN>; 
./run.sh; 

fi

W momencie pisania tego tekstu całość zadziałała mniej więcej poprawnie, jednak za pierwszym razem, gdy to robiłem, nie utworzył się automatycznie token i brakowało go w skrypcie (zamiast tokenu widniał ciąg „_token_”). Zatem kilka słów o tym, gdzie ten token znaleźć.

Klikając w ikonkę z trybikiem (w prawym górnym rogu), pokaże się menu, w którym znajdziemy pozycję Personal access tokens. Tam znajdują się stworzone ręcznie tokeny oraz powinny znaleźć się te potrzebne na czas dołączenia zasobu. Tam też można samemu utworzyć nowy i wkopiować go do skryptu ręcznie.

Jeżeli wszystko z tokenem jest ok, samo uruchomienie skryptu nie powinno przysporzyć problemów. Jedna tylko uwaga dla systemów z systemctl – jeżeli skrypt ./config.sh nie wykona się poprawnie (np z powodów problemów z autoryzacją), nie utworzy się skrypt ./svc.sh.

Na koniec przykład użycia zasobu w pipeline (tylko fragment). W przedstawionym przykładzie odwołuję się bezpośrednio do zasobu, nie całego środowiska.

trigger: none
pool: u4.local

[...]

stages: 

[...]

- stage: Deployment
  dependsOn: Building
  jobs:
  - deployment: u4_dev
    displayName: Local U4 deployment
    environment:
      name: u4
      resourceName: bestyja 
    strategy: 
      runOnce:
        deploy:
          steps:
          - download: current
            displayName: Download artifacts
          - script: ls $(Agent.BuildDirectory)