Azure DevOps pipelines - tips & tricks (3)

Kolejnym ciekawym “ficzerem” w pipeline’ach Azure DevOps jest możliwość uruchomienia całego joba lub pojedynczego stepu na kontenerze z określonego obrazu, innego niż te podstawowe, jakie Microsoft oferuje jako build maszyny. Uzyskujemy to w ten sposób:

resources:
  containers:
  - container: u14
    image: ubuntu:14.04

jobs:
- job: RunInContainer
  container: u14  
  steps:    
  - script: cat /etc/os-release
    displayName: Print OS version   

Lub dla pojedynczego stepu:

resources:
  containers:
  - container: u14
    image: ubuntu:14.04

jobs:
- job: RunInContainer
  steps:    
  - script: cat /etc/os-release
    displayName: Print OS version
	target: u14

Co więcej, możemy skorzystać nie tylko z obrazów dostępnych publicznie w Docker Hub, ale także naszych własnych, które zbudowaliśmy i wgraliśmy do naszego ACR-a.

Po co w ogóle jednak mielibyśmy używać innego obrazu? Do głowy przychodzą mi trzy przypadki:

1. Potrzebujemy jakichś konkretnych narzędzi do wykonania zadania - zamiast tworzyć kroki, w których te narzędzia ściągamy i doinstalowujemy, możemy skorzystać z obrazu, który już je zawiera. Dzięki temu nie tylko scentralizujemy miejsce, w którym np. określamy jakiej wersji danego narzędzia używamy (wiele pipeline’ów skorzysta z jednego obrazu, zamiast wielu pipeline’ów “babrających” się w samodzielnego dociąganie zależności), a wręcz może i “outsource’ujemy” ten problem (jeśli taki obraz już jest na rynku), ale nawet przyspieszymy build: obraz już ma narzędzie gotowe do pracy, nie trzeba tracić czasu na jego ściąganie i instalowanie.
2. Weryfikacja na różnych środowiskach: w połączeniu z użyciem matrix jako strategy dla danego joba możemy uruchomić ten sam zestaw kroków na różnych obrazach. Może na przykład weryfikacja jakiegoś narzędzia, czy działa na Windowsie i Linuksie?
3. W świecie kontenerowym istnieje taki wzorzec, aby skonteneryzowaną aplikację budować też w kontenerze: dzięki temu nie tylko same środowisko uruchomieniowe aplkacji jest stabilne (explicite wyrażone w Dockerfile), ale tak samo środowisko, w którym budujemy aplikację. Zamiast wieloetapowego Dockerfile‘a, który może być trudniejszy do zrozumienia - możemy tę informację o stabilnym środowisku uruchomieniowym przenieść do pipeline’u, uruchamiając build joba w kontenerze. To pewnie jest dyskusyjne, bo na pewno zaletą oryginalnego podejścia jest to, że tuż obok aplikacji (w jej Dockerfile) jest informacja o wszystkich zależnościach - compile-time i run-time.