Udostępnij za pośrednictwem


Dokumentacja usługi ACR Tasks: YAML

Definicja zadania wieloetapowego w usłudze ACR Tasks zapewnia skoncentrowany na kontenerach typ pierwotny obliczeniowy skoncentrowany na tworzeniu, testowaniu i poprawianiu kontenerów. W tym artykule opisano polecenia, parametry, właściwości i składnię plików YAML definiujących zadania wieloetapowe.

Ten artykuł zawiera informacje dotyczące tworzenia plików YAML zadań wieloetapowych dla usługi ACR Tasks. Jeśli chcesz zapoznać się z wprowadzeniem do usługi ACR Tasks, zobacz Omówienie usługi ACR Tasks.

format pliku acr-task.yaml

Usługa ACR Tasks obsługuje deklarację zadania wieloetapowego w standardowej składni YAML. Kroki zadania definiuje się w pliku YAML. Następnie możesz uruchomić zadanie ręcznie, przekazując plik do polecenia az acr run . Możesz też użyć pliku , aby utworzyć zadanie za pomocą polecenia az acr task create , które jest wyzwalane automatycznie w zatwierdzeniu usługi Git, aktualizacji obrazu podstawowego lub harmonogramu. Mimo że ten artykuł odnosi się do acr-task.yaml pliku zawierającego kroki, usługa ACR Tasks obsługuje dowolną prawidłową nazwę pliku z obsługiwanym rozszerzeniem.

Typy pierwotne najwyższego poziomu acr-task.yaml to właściwości zadań, typy kroków i właściwości kroku:

  • Właściwości zadania mają zastosowanie do wszystkich kroków w trakcie wykonywania zadania. Istnieje kilka globalnych właściwości zadań, w tym:
    • version
    • stepTimeout
    • workingDirectory
  • Typy kroków zadań reprezentują typy akcji, które można wykonać w zadaniu. Istnieją trzy typy kroków:
    • build
    • push
    • cmd
  • Właściwości kroku zadania to parametry, które mają zastosowanie do pojedynczego kroku. Istnieje kilka właściwości kroków, w tym:
    • startDelay
    • timeout
    • when
    • ... i wiele innych.

Poniżej przedstawiono podstawowy format acr-task.yaml pliku, w tym niektóre typowe właściwości kroku. Chociaż nie jest wyczerpującą reprezentacją wszystkich dostępnych właściwości kroków lub użycia typu kroku, zawiera krótkie omówienie podstawowego formatu pliku.

version: # acr-task.yaml format version.
stepTimeout: # Seconds each step may take.
steps: # A collection of image or container actions.
  - build: # Equivalent to "docker build," but in a multi-tenant environment
  - push: # Push a newly built or retagged image to a registry.
    when: # Step property that defines either parallel or dependent step execution.
  - cmd: # Executes a container, supports specifying an [ENTRYPOINT] and parameters.
    startDelay: # Step property that specifies the number of seconds to wait before starting execution.

Obsługiwane rozszerzenia nazw plików zadań

Usługa ACR Tasks zarezerwowała kilka rozszerzeń nazw plików, w tym .yaml, które będą przetwarzane jako plik zadania. Każde rozszerzenie, które nie znajduje się na poniższej liście, jest uznawane przez usługę ACR Tasks za plik Dockerfile: .yaml, .yml, .toml, .json, .sh, .bash, .zsh, .ps1, .ps, .cmd, .bat, .ts, .js, .php, .py, .rb, .lua

YAML jest jedynym formatem pliku obsługiwanym obecnie przez usługę ACR Tasks. Pozostałe rozszerzenia nazw plików są zarezerwowane dla możliwej przyszłej obsługi.

Uruchamianie przykładowych zadań

W poniższych sekcjach tego artykułu znajduje się kilka przykładowych plików zadań. Przykładowe zadania znajdują się w publicznym repozytorium GitHub Azure-Samples /acr-tasks. Można je uruchomić za pomocą polecenia interfejsu wiersza polecenia platformy Azure az acr run. Przykładowe polecenia są podobne do następujących:

az acr run -f build-push-hello-world.yaml https://github.com/Azure-Samples/acr-tasks.git

Formatowanie przykładowych poleceń zakłada, że skonfigurowano domyślny rejestr w interfejsie wiersza polecenia platformy Azure, więc pomijają --registry parametr . Aby skonfigurować rejestr domyślny, użyj polecenia az config z set poleceniem defaults.acr=REGISTRY_NAME , które akceptuje parę wartości klucza.

Aby na przykład skonfigurować interfejs wiersza polecenia platformy Azure z domyślnym rejestrem o nazwie "myregistry":

az config set defaults.acr=myregistry

Właściwości zadania

Właściwości zadania są zwykle wyświetlane w górnej acr-task.yaml części pliku i są właściwościami globalnymi, które mają zastosowanie w trakcie pełnego wykonywania kroków zadania. Niektóre z tych właściwości globalnych można zastąpić w ramach pojedynczego kroku.

Właściwość Type Opcjonalnie opis Zastępowanie obsługiwane Domyślna wartość
version string Tak Wersja acr-task.yaml pliku analizowana przez usługę ACR Tasks. Chociaż usługa ACR Tasks stara się zachować zgodność z poprzednimi wersjami, ta wartość umożliwia usłudze ACR Tasks zachowanie zgodności w zdefiniowanej wersji. Jeśli wartość jest nieokreślona, wartość domyślna to v1.0.0. Nie dotyczy v1.0.0
stepTimeout int (sekundy) Tak Maksymalna liczba sekund, które można uruchomić. stepTimeout Jeśli właściwość jest określona w zadaniu, ustawia domyślną timeout właściwość wszystkich kroków. timeout Jeśli właściwość jest określona w kroku, zastępuje stepTimeout właściwość dostarczoną przez zadanie.

Suma wartości limitu czasu kroku dla zadania powinna być równa wartości właściwości przebiegu timeout zadania (na przykład ustawionej az acr task create przez przekazanie --timeout polecenia). Jeśli wartość przebiegu timeout zadań jest mniejsza, ma priorytet.
Tak 600 (10 minut)
workingDirectory string Tak Katalog roboczy kontenera podczas wykonywania. Jeśli właściwość jest określona w zadaniu, ustawia domyślną workingDirectory właściwość wszystkich kroków. Jeśli zostanie określony w kroku, zastępuje właściwość podaną przez zadanie. Tak c:\workspace w systemie Windows lub /workspace w systemie Linux
env [ciąg, ciąg, ...] Tak Tablica ciągów w key=value formacie definiującym zmienne środowiskowe zadania. Jeśli właściwość jest określona w zadaniu, ustawia domyślną env właściwość wszystkich kroków. Jeśli zostanie określony w kroku, zastępuje wszystkie zmienne środowiskowe dziedziczone z zadania. Tak None
secrets [wpis tajny, wpis tajny, ...] Tak Tablica obiektów tajnych. Nie. Brak
networks [sieć, sieć, ...] Tak Tablica obiektów sieciowych . Nie. Brak
volumes [wolumin, wolumin, ...] Tak Tablica obiektów woluminów. Określa woluminy z zawartością źródłową do zainstalowania w kroku. Nie. Brak

wpis tajny

Obiekt tajny ma następujące właściwości.

Właściwość Type Opcjonalnie opis Domyślna wartość
id string Nie Identyfikator wpisu tajnego. Brak
keyvault string Tak Adres URL wpisu tajnego usługi Azure Key Vault. Brak
clientID string Tak Identyfikator klienta tożsamości zarządzanej przypisanej przez użytkownika dla zasobów platformy Azure. Brak

network

Obiekt sieciowy ma następujące właściwości.

Właściwość Type Opcjonalnie opis Domyślna wartość
name string Nie Nazwa sieci. Brak
driver string Tak Sterownik do zarządzania siecią. Brak
ipv6 bool Tak Czy włączono sieć IPv6. false
skipCreation bool Tak Czy pominąć tworzenie sieci. false
isDefault bool Tak Czy sieć jest domyślną siecią dostarczaną z usługą Azure Container Registry. false

wolumin

Obiekt woluminu ma następujące właściwości.

Właściwość Type Opcjonalnie opis Domyślna wartość
name string Nie Nazwa woluminu do zainstalowania. Może zawierać tylko znaki alfanumeryczne, '-' i '_'. Brak
secret map[string]string Nie. Każdy klucz mapy jest nazwą pliku utworzonego i wypełnionego w woluminie. Każda wartość to wersja ciągu wpisu tajnego. Wartości wpisów tajnych muszą być zakodowane w formacie Base64. Brak

Typy kroków zadania

Usługa ACR Tasks obsługuje trzy typy kroków. Każdy typ kroku obsługuje kilka właściwości, szczegółowo opisanych w sekcji dla każdego typu kroku.

Typ kroku opis
build Tworzy obraz kontenera przy użyciu znanej docker build składni.
push docker push Wykonuje nowo skompilowane lub ponownie oznaczone obrazy do rejestru kontenerów. Obsługiwane są usługi Azure Container Registry, inne rejestry prywatne i publiczne centrum Docker Hub.
cmd Uruchamia kontener jako polecenie z parametrami przekazywanymi do kontenera [ENTRYPOINT]. cmd Typ kroku obsługuje parametry, takie jak env, detachi inne znane docker run opcje poleceń, włączając jednostkę i testowanie funkcjonalne z równoczesnymi wykonywaniem kontenera.

build

Tworzenie obrazu kontenera. build Typ kroku reprezentuje wielodostępne, bezpieczne środki uruchamiania docker build w chmurze jako pierwszoklasowy typ pierwotny.

Składnia: kompilacja

version: v1.1.0
steps:
  - [build]: -t [imageName]:[tag] -f [Dockerfile] [context]
    [property]: [value]

Uruchom polecenie az acr run, aby pobrać wersję platformy Docker.

az acr run -r $ACR_NAME --cmd "docker version" /dev/null

Dodaj zmienną środowiskową DOCKER_BUILDKIT=1 w pliku yaml, aby włączyć buildkit i używać z buildkitprogramem secret .

Typ build kroku obsługuje parametry w poniższej tabeli. Typ build kroku obsługuje również wszystkie opcje kompilacji polecenia kompilacji platformy Docker, takie jak --build-arg ustawianie zmiennych czasu kompilacji.

Parametr Opis Opcjonalnie
-t | --image Definiuje w pełni kwalifikowany image:tag obraz skompilowany.

Ponieważ obrazy mogą być używane do weryfikacji zadań wewnętrznych, takich jak testy funkcjonalne, nie wszystkie obrazy wymagają push rejestru. Jednak aby można było utworzyć obraz w ramach wykonywania zadania, obraz musi mieć nazwę do odwołania.

W przeciwieństwie do az acr buildprogramu uruchomienie usługi ACR Tasks nie zapewnia domyślnego zachowania wypychania. W przypadku usługi ACR Tasks domyślny scenariusz zakłada możliwość kompilowania, weryfikowania, a następnie wypychania obrazu. Zobacz wypychanie , jak opcjonalnie wypychać wbudowane obrazy.
Tak
-f | --file Określa plik Dockerfile przekazany do .docker build Jeśli nie zostanie określony, przyjmuje się domyślny plik Dockerfile w katalogu głównym kontekstu. Aby określić plik Dockerfile, przekaż nazwę pliku względem katalogu głównego kontekstu. Tak
context Katalog główny przekazany do docker build. Katalog główny każdego zadania jest ustawiony na udostępniony katalog roboczy i zawiera katalog główny skojarzonego katalogu sklonowanego usługi Git. Nie.

Właściwości: kompilacja

Typ build kroku obsługuje następujące właściwości. Szczegółowe informacje o tych właściwościach znajdują się w sekcji Właściwości kroku zadania w tym artykule.

Właściwości Typ Wymagania
detach bool Opcjonalnie
disableWorkingDirectoryOverride bool Opcjonalnie
entryPoint string Opcjonalnie
env [ciąg, ciąg, ...] Opcjonalnie
expose [ciąg, ciąg, ...] Opcjonalnie
id string Opcjonalnie
ignoreErrors bool Opcjonalnie
isolation string Opcjonalnie
keep bool Opcjonalnie
network obiekt Opcjonalnie
ports [ciąg, ciąg, ...] Opcjonalnie
pull bool Opcjonalnie
repeat int Opcjonalnie
retries int Opcjonalnie
retryDelay int (sekundy) Opcjonalnie
secret obiekt Opcjonalnie
startDelay int (sekundy) Opcjonalnie
timeout int (sekundy) Opcjonalnie
volumeMount obiekt Opcjonalnie
when [ciąg, ciąg, ...] Opcjonalnie
workingDirectory string Opcjonalnie

Przykłady: kompilacja

Kompilowanie obrazu — kontekst w katalogu głównym

az acr run -f build-hello-world.yaml https://github.com/AzureCR/acr-tasks-sample.git
version: v1.1.0
steps:
  - build: -t $Registry/hello-world -f hello-world.dockerfile .

Kompilowanie obrazu — kontekst w podkatalogu

version: v1.1.0
steps:
  - build: -t $Registry/hello-world -f hello-world.dockerfile ./subDirectory

Zmienna dynamiczna przekazująca w zadaniach usługi ACR

Podczas pracy z zadaniami usługi Azure Container Registry (ACR) może być konieczne przekazanie różnych wartości do procesu kompilacji bez konieczności zmieniania definicji zadania przy użyciu --set flagi z poleceniem az acr task run .

Przykład: ustawianie tagu obrazu w czasie wykonywania

Załóżmy, że masz zadanie usługi ACR zdefiniowane w acr-task.yml pliku z symbolem zastępczym tagu obrazu:

steps:
  - build: -t $Registry/hello-world:{{.Values.tag}}

Zadanie można wyzwolić i ustawić zmienną tag na v2 w czasie wykonywania przy użyciu następującego polecenia interfejsu wiersza polecenia platformy Azure:

az acr task run --registry myregistry --name mytask --set tag=v2

To polecenie uruchomi zadanie usługi ACR o nazwie mytask i skompiluje obraz przy użyciu tagu v2 , przesłaniając symbol zastępczy w acr-task.yml pliku.

Takie podejście umożliwia dostosowanie w potokach ciągłej integracji/ciągłego wdrażania, umożliwiając dynamiczne dostosowywanie parametrów na podstawie bieżących potrzeb bez zmieniania definicji zadań.

push

Wypchnij co najmniej jeden skompilowany lub ponownie oznaczony obraz do rejestru kontenerów. Obsługuje wypychanie do prywatnych rejestrów, takich jak usługa Azure Container Registry lub publiczne centrum Docker Hub.

Składnia: wypychanie

Typ push kroku obsługuje kolekcję obrazów. Składnia kolekcji YAML obsługuje wbudowane i zagnieżdżone formaty. Wypychanie pojedynczego obrazu jest zwykle reprezentowane przy użyciu składni wbudowanej:

version: v1.1.0
steps:
  # Inline YAML collection syntax
  - push: ["$Registry/hello-world:$ID"]

Aby zwiększyć czytelność, użyj składni zagnieżdżonej podczas wypychania wielu obrazów:

version: v1.1.0
steps:
  # Nested YAML collection syntax
  - push:
    - $Registry/hello-world:$ID
    - $Registry/hello-world:latest

Właściwości: wypychanie

Typ push kroku obsługuje następujące właściwości. Szczegółowe informacje o tych właściwościach znajdują się w sekcji Właściwości kroku zadania w tym artykule.

Właściwość Type Wymagania
env [ciąg, ciąg, ...] Opcjonalnie
id string Opcjonalnie
ignoreErrors bool Opcjonalnie
startDelay int (sekundy) Opcjonalnie
timeout int (sekundy) Opcjonalnie
when [ciąg, ciąg, ...] Opcjonalnie

Przykłady: wypychanie

Wypychanie wielu obrazów

az acr run -f build-push-hello-world.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  - build: -t $Registry/hello-world:$ID -f hello-world.dockerfile .
  - push: 
    - $Registry/hello-world:$ID

Kompilowanie, wypychanie i uruchamianie

az acr run -f build-run-hello-world.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  - build: -t $Registry/hello-world:$ID -f hello-world.dockerfile .
  - push:
    - $Registry/hello-world:$ID
  - cmd: $Registry/hello-world:$ID

Cmd

Typ cmd kroku uruchamia kontener.

Składnia: cmd

version: v1.1.0
steps:
  - [cmd]: [containerImage]:[tag (optional)] [cmdParameters to the image]

Właściwości: cmd

Typ cmd kroku obsługuje następujące właściwości:

Właściwość Type Wymagania
detach bool Opcjonalnie
disableWorkingDirectoryOverride bool Opcjonalnie
entryPoint string Opcjonalnie
env [ciąg, ciąg, ...] Opcjonalnie
expose [ciąg, ciąg, ...] Opcjonalnie
id string Opcjonalnie
ignoreErrors bool Opcjonalnie
isolation string Opcjonalnie
keep bool Opcjonalnie
network obiekt Opcjonalnie
ports [ciąg, ciąg, ...] Opcjonalnie
pull bool Opcjonalnie
repeat int Opcjonalnie
retries int Opcjonalnie
retryDelay int (sekundy) Opcjonalnie
secret obiekt Opcjonalnie
startDelay int (sekundy) Opcjonalnie
timeout int (sekundy) Opcjonalnie
volumeMount obiekt Opcjonalnie
when [ciąg, ciąg, ...] Opcjonalnie
workingDirectory string Opcjonalnie

Szczegółowe informacje o tych właściwościach można znaleźć w sekcji Właściwości kroku zadania w tym artykule.

Przykłady: cmd

Uruchamianie obrazu hello-world

To polecenie wykonuje hello-world.yaml plik zadania, który odwołuje się do obrazu hello-world w usłudze Docker Hub.

az acr run -f hello-world.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  - cmd: mcr.microsoft.com/hello-world

Uruchamianie obrazu powłoki bash i echo "hello world"

To polecenie wykonuje bash-echo.yaml plik zadania, który odwołuje się do obrazu powłoki bash w usłudze Docker Hub.

az acr run -f bash-echo.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  - cmd: bash echo hello world

Uruchamianie określonego tagu obrazu powłoki bash

Aby uruchomić określoną wersję obrazu, określ tag w pliku cmd.

To polecenie wykonuje bash-echo-3.yaml plik zadania, który odwołuje się do obrazu bash:3.0 w usłudze Docker Hub.

az acr run -f bash-echo-3.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  - cmd: bash:3.0 echo hello world

Uruchamianie obrazów niestandardowych

Typ cmd kroku odwołuje się do obrazów przy użyciu standardowego docker run formatu. Przyjmuje się, że obrazy, które nie są poprzedzone rejestrem, pochodzą z docker.io. Poprzedni przykład może być równie reprezentowany jako:

version: v1.1.0
steps:
  - cmd: docker.io/bash:3.0 echo hello world

Korzystając ze standardowej docker run konwencji referencyjnej obrazu, cmd można uruchamiać obrazy z dowolnego rejestru prywatnego lub publicznego centrum Docker Hub. Jeśli odwołujesz się do obrazów w tym samym rejestrze, w którym jest wykonywane zadanie usługi ACR, nie musisz określać żadnych poświadczeń rejestru.

  • Uruchom obraz z rejestru kontenerów platformy Azure. W poniższym przykładzie założono, że masz rejestr o nazwie myregistryi obraz myimage:mytagniestandardowy .

    version: v1.1.0
    steps:
        - cmd: myregistry.azurecr.io/myimage:mytag
    
  • Uogólnij odwołanie do rejestru za pomocą zmiennej Run lub aliasu

    Zamiast trwale kodować nazwę rejestru w acr-task.yaml pliku, możesz zwiększyć jego przenośność przy użyciu zmiennej Run lub aliasu. Zmienna Run.Registry lub $Registry alias rozszerza się w czasie wykonywania na nazwę rejestru, w którym jest wykonywane zadanie.

    Aby na przykład uogólnić poprzednie zadanie tak, aby działało w dowolnym rejestrze kontenerów platformy Azure, należy odwołać się do zmiennej $Registry w nazwie obrazu:

    version: v1.1.0
    steps:
      - cmd: $Registry/myimage:mytag
    

Uzyskiwanie dostępu do woluminów wpisów tajnych

Właściwość volumes umożliwia określenie woluminów i ich zawartości wpisów tajnych dla build i cmd kroków w zadaniu. W każdym kroku opcjonalna volumeMounts właściwość zawiera listę woluminów i odpowiadające im ścieżki kontenera do zainstalowania w kontenerze w tym kroku. Wpisy tajne są udostępniane jako pliki w ścieżce instalacji każdego woluminu.

Wykonaj zadanie i zainstaluj dwa wpisy tajne w kroku: jeden przechowywany w magazynie kluczy i jeden określony w wierszu polecenia:

az acr run -f mounts-secrets.yaml --set-secret mysecret=abcdefg123456 https://github.com/Azure-Samples/acr-tasks.git
# This template demonstrates mounting a custom volume into a container at a CMD step
secrets:
  - id: sampleSecret
    keyvault: https://myacbvault2.vault.azure.net/secrets/SampleSecret # Replace with valid keyvault with access

volumes:
  - name: mysecrets
    secret:
      mysecret1: {{.Secrets.sampleSecret | b64enc}}
      mysecret2: {{.Values.mysecret | b64enc}}

steps:
  - cmd: bash cat /run/test/mysecret1 /run/test/mysecret2
    volumeMounts:
      - name: mysecrets
        mountPath: /run/test

Właściwości kroku zadania

Każdy typ kroku obsługuje kilka właściwości odpowiednich dla jego typu. W poniższej tabeli zdefiniowano wszystkie dostępne właściwości kroku. Nie wszystkie typy kroków obsługują wszystkie właściwości. Aby zobaczyć, które z tych właściwości są dostępne dla każdego typu kroku, zobacz sekcje referencyjne typu cmd, kompilacji i kroku wypychania .

Właściwość Type Opcjonalnie opis Domyślna wartość
detach bool Tak Czy kontener powinien być odłączony podczas uruchamiania. false
disableWorkingDirectoryOverride bool Tak Czy wyłączyć workingDirectory funkcję zastępowania. Użyj tej funkcji w połączeniu z elementem , workingDirectory aby mieć pełną kontrolę nad katalogiem roboczym kontenera. false
entryPoint string Tak [ENTRYPOINT] Zastępuje kontener kroku. Brak
env [ciąg, ciąg, ...] Tak Tablica ciągów w key=value formacie definiującym zmienne środowiskowe dla kroku. Brak
expose [ciąg, ciąg, ...] Tak Tablica portów uwidocznionych z kontenera. Brak
id string Tak Jednoznacznie identyfikuje krok w zadaniu. Inne kroki w zadaniu mogą odwoływać się do kroku id, na przykład na potrzeby sprawdzania zależności za pomocą polecenia when.

Jest id to również nazwa uruchomionego kontenera. Procesy uruchomione w innych kontenerach w zadaniu mogą odwoływać się do id nazwy hosta DNS lub na potrzeby uzyskiwania do niego dostępu za pomocą dzienników platformy Docker [id], na przykład.
acb_step_%d, gdzie %d jest 0-opartym na indeksie kroku od góry do góry w pliku YAML
ignoreErrors bool Tak Czy oznaczyć krok jako udany, niezależnie od tego, czy wystąpił błąd podczas wykonywania kontenera. false
isolation string Tak Poziom izolacji kontenera. default
keep bool Tak Czy kontener kroku powinien być przechowywany po wykonaniu. false
network obiekt Tak Identyfikuje sieć, w której działa kontener. Brak
ports [ciąg, ciąg, ...] Tak Tablica portów publikowanych z kontenera do hosta. Brak
pull bool Tak Czy wymusić ściągnięcie kontenera przed jego wykonaniem, aby zapobiec wszelkim zachowaniom buforowania. false
privileged bool Tak Czy uruchamiać kontener w trybie uprzywilejowanym. false
repeat int Tak Liczba ponownych prób powtórzenia wykonania kontenera. 0
retries int Tak Liczba ponownych prób w przypadku niepowodzenia wykonywania kontenera. Próba ponawiania jest podejmowana tylko wtedy, gdy kod zakończenia kontenera jest inny niż zero. 0
retryDelay int (sekundy) Tak Opóźnienie w sekundach między ponowną próbą wykonania kontenera. 0
secret obiekt Tak Identyfikuje wpis tajny usługi Azure Key Vault lub tożsamość zarządzaną dla zasobów platformy Azure. Brak
startDelay int (sekundy) Tak Liczba sekund opóźnienia wykonania kontenera. 0
timeout int (sekundy) Tak Maksymalna liczba sekund, przez które krok może zostać wykonany przed zakończeniem. 600
when [ciąg, ciąg, ...] Tak Konfiguruje zależność kroku od jednego lub kilku innych kroków w ramach zadania. Brak
user string Tak Nazwa użytkownika lub identyfikator UID kontenera Brak
workingDirectory string Tak Ustawia katalog roboczy dla kroku. Domyślnie usługa ACR Tasks tworzy katalog główny jako katalog roboczy. Jeśli jednak kompilacja ma kilka kroków, wcześniejsze kroki mogą udostępniać artefakty później, określając ten sam katalog roboczy. c:\workspace w systemie Windows lub /workspace w systemie Linux

volumeMount

Obiekt volumeMount ma następujące właściwości.

Właściwość Type Opcjonalnie opis Domyślna wartość
name string Nie Nazwa woluminu do zainstalowania. Musi dokładnie odpowiadać nazwie z volumes właściwości. Brak
mountPath string nie Ścieżka bezwzględna do instalowania plików w kontenerze. Brak

Przykłady: właściwości kroku zadania

Przykład: id

Skompiluj dwa obrazy, tworząc obraz testu funkcjonalnego. Każdy krok jest identyfikowany przez unikatowy id , który inny krok w odwołaniu do zadania w ich when właściwości.

az acr run -f when-parallel-dependent.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  # build website and func-test images, concurrently
  - id: build-hello-world
    build: -t $Registry/hello-world:$ID -f hello-world.dockerfile .
    when: ["-"]
  - id: build-hello-world-test
    build: -t hello-world-test -f hello-world.dockerfile .
    when: ["-"]
  # run built images to be tested
  - id: hello-world
    cmd: $Registry/hello-world:$ID
    when: ["build-hello-world"]
  - id: func-tests
    cmd: hello-world-test
    env:
      - TEST_TARGET_URL=hello-world
    when: ["hello-world"]
  # push hello-world if func-tests are successful  
  - push: ["$Registry/hello-world:$ID"]
    when: ["func-tests"]

Przykład: kiedy

Właściwość when określa zależność kroku od innych kroków w ramach zadania. Obsługuje dwie wartości parametrów:

  • when: ["-"] — nie wskazuje zależności od innych kroków. Krok określający when: ["-"] spowoduje natychmiastowe rozpoczęcie wykonywania i włączenie współbieżnego wykonywania kroku.
  • when: ["id1", "id2"] — Wskazuje, że krok jest zależny od kroków z id "id1" i id "id2". Ten krok nie zostanie wykonany, dopóki nie zostaną wykonane zarówno kroki "id1" i "id2".

Jeśli when nie określono w kroku, ten krok jest zależny od ukończenia poprzedniego kroku w acr-task.yaml pliku.

Sekwencyjne wykonywanie kroku bez whenpolecenia :

az acr run -f when-sequential-default.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
    - cmd: bash echo one
    - cmd: bash echo two
    - cmd: bash echo three

Sekwencyjne wykonanie kroku za pomocą polecenia when:

az acr run -f when-sequential-id.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
    - id: step1
      cmd: bash echo one
    - id: step2
      cmd: bash echo two
      when: ["step1"]
    - id: step3
      cmd: bash echo three
      when: ["step2"]

Kompilacja obrazów równoległych:

az acr run -f when-parallel.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  # build website and func-test images, concurrently
  - id: build-hello-world
    build: -t $Registry/hello-world:$ID -f hello-world.dockerfile .
    when: ["-"]
  - id: build-hello-world-test
    build: -t hello-world-test -f hello-world.dockerfile .
    when: ["-"]

Równoległe kompilowanie obrazów i testowanie zależne:

az acr run -f when-parallel-dependent.yaml https://github.com/Azure-Samples/acr-tasks.git
version: v1.1.0
steps:
  # build website and func-test images, concurrently
  - id: build-hello-world
    build: -t $Registry/hello-world:$ID -f hello-world.dockerfile .
    when: ["-"]
  - id: build-hello-world-test
    build: -t hello-world-test -f hello-world.dockerfile .
    when: ["-"]
  # run built images to be tested
  - id: hello-world
    cmd: $Registry/hello-world:$ID
    when: ["build-hello-world"]
  - id: func-tests
    cmd: hello-world-test
    env:
      - TEST_TARGET_URL=hello-world
    when: ["hello-world"]
  # push hello-world if func-tests are successful  
  - push: ["$Registry/hello-world:$ID"]
    when: ["func-tests"]

Uruchamianie zmiennych

Usługa ACR Tasks zawiera domyślny zestaw zmiennych, które są dostępne do wykonania kroków zadań. Dostęp do tych zmiennych można uzyskać przy użyciu formatu {{.Run.VariableName}}, gdzie VariableName jest jednym z następujących elementów:

  • Run.ID
  • Run.SharedVolume
  • Run.Registry
  • Run.RegistryName
  • Run.Date
  • Run.OS
  • Run.Architecture
  • Run.Commit
  • Run.Branch
  • Run.TaskName

Nazwy zmiennych są zwykle objaśniające. Szczegóły są zgodne z często używanymi zmiennymi. W wersji v1.1.0YAML można użyć skróconego, wstępnie zdefiniowanego aliasu zadania zamiast większości zmiennych uruchamiania. Na przykład zamiast {{.Run.Registry}}elementu użyj aliasu $Registry .

Run.ID

Każde uruchomienie, za pośrednictwem az acr runmetody lub wyzwalacza oparte na wykonywaniu zadań utworzonych za pomocą az acr task createelementu , ma unikatowy identyfikator. Identyfikator reprezentuje aktualnie wykonywany przebieg.

Zazwyczaj używane do unikatowego tagowania obrazu:

version: v1.1.0
steps:
    - build: -t $Registry/hello-world:$ID .

Run.SharedVolume

Unikatowy identyfikator udostępnionego woluminu, który jest dostępny we wszystkich krokach zadania. Wolumin jest instalowany c:\workspace w systemie Windows lub /workspace w systemie Linux.

Run.Registry

W pełni kwalifikowana nazwa serwera rejestru. Zazwyczaj służy do ogólnego odwołowania się do rejestru, w którym jest uruchamiane zadanie.

version: v1.1.0
steps:
  - build: -t $Registry/hello-world:$ID .

Run.RegistryName

Nazwa rejestru kontenerów. Zazwyczaj używane w krokach zadań, które nie wymagają w pełni kwalifikowanej nazwy serwera, na przykład cmd kroki uruchamiające polecenia interfejsu wiersza polecenia platformy Azure w rejestrach.

version 1.1.0
steps:
# List repositories in registry
- cmd: az login --identity
- cmd: az acr repository list --name $RegistryName

Run.Date

Bieżąca godzina UTC uruchomienia.

Run.Commit

W przypadku zadania wyzwalanego przez zatwierdzenie w repozytorium GitHub identyfikator zatwierdzenia.

Run.Branch

W przypadku zadania wyzwalanego przez zatwierdzenie w repozytorium GitHub nazwa gałęzi.

Aliasy

Od wersji v1.1.0usługa ACR Tasks obsługuje aliasy, które są dostępne do wykonania kroków zadań. Aliasy są podobne do aliasów (skrótów poleceń) obsługiwanych w powłoce bash i innych powłokach poleceń.

Za pomocą aliasu można uruchomić dowolne polecenie lub grupę poleceń (w tym opcje i nazwy plików), wprowadzając jedno słowo.

Usługa ACR Tasks obsługuje kilka wstępnie zdefiniowanych aliasów, a także utworzonych aliasów niestandardowych.

Wstępnie zdefiniowane aliasy

Następujące aliasy zadań są dostępne do użycia zamiast zmiennych uruchamiania:

Alias Uruchamianie zmiennej
ID Run.ID
SharedVolume Run.SharedVolume
Registry Run.Registry
RegistryName Run.RegistryName
Date Run.Date
OS Run.OS
Architecture Run.Architecture
Commit Run.Commit
Branch Run.Branch

W krokach zadania poprzedź alias dyrektywą $ , jak w tym przykładzie:

version: v1.1.0
steps:
  - build: -t $Registry/hello-world:$ID -f hello-world.dockerfile .

Aliasy obrazów

Każdy z poniższych aliasów wskazuje stabilny obraz w usłudze Microsoft Container Registry (MCR). Każdy z nich można odwołać się do każdej z nich w cmd sekcji pliku zadania bez użycia dyrektywy.

Alias Obraz
acr mcr.microsoft.com/acr/acr-cli:0.5
az mcr.microsoft.com/acr/azure-cli:7ee1d7f
bash mcr.microsoft.com/acr/bash:7ee1d7f
curl mcr.microsoft.com/acr/curl:7ee1d7f

Poniższe przykładowe zadanie używa kilku aliasów do przeczyszczania tagów obrazów starszych niż 7 dni w repozytorium samples/hello-world w rejestrze uruchomień:

version: v1.1.0
steps:
  - cmd: acr tag list --registry $RegistryName --repository samples/hello-world
  - cmd: acr purge --registry $RegistryName --filter samples/hello-world:.* --ago 7d

Alias niestandardowy

Zdefiniuj alias niestandardowy w pliku YAML i użyj go, jak pokazano w poniższym przykładzie. Alias może zawierać tylko znaki alfanumeryczne. Domyślną dyrektywą do rozwinięcia aliasu $ jest znak .

version: v1.1.0
alias:
  values:
    repo: myrepo
steps:
  - build: -t $Registry/$repo/hello-world:$ID -f Dockerfile .

Możesz połączyć się z zdalnym lub lokalnym plikiem YAML dla niestandardowych definicji aliasu. Poniższy przykład zawiera linki do pliku YAML w usłudze Azure Blob Storage:

version: v1.1.0
alias:
  src:  # link to local or remote custom alias files
    - 'https://link/to/blob/remoteAliases.yml?readSasToken'
[...]

Następne kroki

Aby zapoznać się z omówieniem zadań wieloetapowych, zobacz Uruchamianie wieloetapowych zadań kompilacji, testowania i stosowania poprawek w zadaniach usługi ACR.

W przypadku kompilacji jednoetapowych zobacz omówienie usługi ACR Tasks.