コンテナージョブの定義 (YAML)

Azure Pipelines |Azure DevOps Server 2020 |Azure DevOps Server 2019

既定では、 ジョブエージェント がインストールされているホストコンピューター上で実行されます。 これは便利な機能であり、通常は Azure Pipelines の導入を開始したばかりのプロジェクトに適しています。 時間の経過と共に、タスクを実行するコンテキストをより詳細に制御することが必要になる場合があります。 YAML パイプラインは、このレベルの制御のためにコンテナージョブを提供します。

Linux および Windows エージェントでは、ジョブは ホスト または コンテナーで実行できます。 (MacOS および Red Hat Enterprise Linux 6 では、コンテナージョブは使用できません)。コンテナーを使用すると、ホストから分離でき、特定のバージョンのツールと依存関係をピン留めすることができます。 ホストジョブでは、初期セットアップとインフラストラクチャの保守を減らす必要があります。

コンテナーは、ホストオペレーティングシステムに対して簡易な抽象化を提供します。 ビルドに必要なオペレーティングシステム、ツール、および依存関係の正確なバージョンを選択できます。 パイプラインでコンテナーを指定すると、エージェントは最初にコンテナーをフェッチして開始します。 次に、ジョブの各ステップがコンテナー内で実行されます。 入れ子になったコンテナーを持つことはできません。 コンテナーは、エージェントが既にコンテナー内で実行されている場合はサポートされません。

個々のステップレベルできめ細かく制御する必要がある場合は、ステップ ターゲット を使用して、各ステップに対してコンテナーまたはホストを選択できます。

必要条件

Linux ベースのコンテナー

Azure Pipelines システムでは、Linux ベースのコンテナーに次のものが必要です。

  • Bash
  • glibc ベース
  • (エージェントが提供する) Node.js を実行できる
  • がを定義していません。 ENTRYPOINT
  • USER``groupaddとその他の特権コマンドにアクセスできるsudo

エージェントホストで、次のことを行います。

  • Docker がインストールされていることを確認する
  • エージェントには、Docker デーモンにアクセスするためのアクセス許可が必要です。

コンテナーにこれらの各ツールが使用可能であることを確認してください。 Docker Hub で使用できる非常に削除されたコンテナー (特に、Alpine Linux に基づくコンテナー) の中には、これらの最小要件を満たしていないものがあります。 を含むコンテナーが ENTRYPOINT 機能しない可能性があり docker create ます。これは Azure Pipelines がコンテナーを待機しており、 docker exec コンテナーが常に稼働していることを期待する一連のコマンドを実行するためです。

注意

Windows ベースの Linux コンテナーの場合は、Node.js を事前にインストールする必要があります。

Windows コンテナー

Azure Pipelines は、 Windows コンテナーを実行することもできます。 Windows Server バージョン 1803 以降が必要です。 Docker がインストールされている必要があります。 パイプラインエージェントが Docker デーモンにアクセスするためのアクセス許可を持っていることを確認してください。

Windows コンテナーは、Node.js の実行をサポートしている必要があります。 ベースの Windows Nano Server コンテナーに、ノードの実行に必要な依存関係がありません。

ホストされたエージェント

windows-2019とのイメージのみが、 ubuntu-* 実行中のコンテナーをサポートします。 MacOS イメージは、実行中のコンテナーをサポートしていません。

1つのジョブ

単純な例を次に示します。

pool:
  vmImage: 'ubuntu-18.04'

container: ubuntu:18.04

steps:
- script: printenv

これにより、 ubuntu 18.04 Docker Hub からタグ付けされたイメージをフェッチし、コンテナーを起動するようにシステムに指示します。 コマンドが printenv 実行されると、コンテナー内に発生し ubuntu:18.04 ます。

Windows の例:

pool:
  vmImage: 'windows-2019'

container: mcr.microsoft.com/windows/servercore:ltsc2019

steps:
- script: set

注意

Windows では、ホストとコンテナーのカーネルバージョンが一致している必要があります。 この例では Windows 2019 イメージを使用するため、コンテナーにはタグを使用し 2019 ます。

複数のジョブ

コンテナーは、複数の ジョブで同じ手順を実行する場合にも役立ちます。 次の例では、同じ手順を複数のバージョンの Ubuntu Linux で実行します。 ( jobs 1 つのジョブしか定義されていないため、キーワードについては説明する必要はありません)。

pool:
  vmImage: 'ubuntu-18.04'

strategy:
  matrix:
    ubuntu14:
      containerImage: ubuntu:14.04
    ubuntu16:
      containerImage: ubuntu:16.04
    ubuntu18:
      containerImage: ubuntu:18.04

container: $[ variables['containerImage'] ]

steps:
- script: printenv

エンドポイント

コンテナーは、Docker Hub 以外のレジストリでホストできます。 Azure Container Registryまたは別のプライベートコンテナーレジストリでイメージをホストするには、サービス接続をプライベートレジストリに追加します。 次に、コンテナーの仕様で参照できます。

container:
  image: registry:ubuntu1604
  endpoint: private_dockerhub_connection

steps:
- script: echo hello

or

container:
  image: myprivate.azurecr.io/windowsservercore:1803
  endpoint: my_acr_connection

steps:
- script: echo hello

他のコンテナーレジストリも機能する場合があります。 AWS の資格情報を Docker が認証に使用できるものに変換するために必要な追加のクライアントツールがあるため、Amazon ECR は現在機能していません。

注意

エージェントの Red Hat Enterprise Linux 6 ビルドでは、コンテナージョブは実行されません。 Red Hat Enterprise Linux 7 以降など、別の Linux フレーバーを選択します。

オプション

コンテナーの起動を制御する必要がある場合は、を指定でき options ます。

container:
  image: ubuntu:18.04
  options: --hostname container-test --ip 192.168.0.1

steps:
- script: echo hello

を実行 docker create --help すると、サポートされているオプションの一覧が表示されます。 docker create コマンドで使用できる任意のオプションを使用できます。

再利用可能なコンテナーの定義

次の例では、コンテナーが resources セクションで定義されています。 各コンテナーは、割り当てられたエイリアスを参照することによって、後で参照されます。 (ここでは、わかりやすくするためにキーワードを明示的に示して jobs います)。

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

  - container: u16
    image: ubuntu:16.04

  - container: u18
    image: ubuntu:18.04

jobs:
- job: RunInContainer
  pool:
    vmImage: 'ubuntu-18.04'

  strategy:
    matrix:
      ubuntu14:
        containerResource: u14
      ubuntu16:
        containerResource: u16
      ubuntu18:
        containerResource: u18

  container: $[ variables['containerResource'] ]

  steps:
  - script: printenv

Glibc ベースではないコンテナー

Azure Pipelines エージェントは、タスクとスクリプトを実行するために必要な Node.js のコピーを提供します。 Node.js のバージョンは、ホストされているクラウド (通常は glibc) で使用している C ランタイムに対してコンパイルされます。 一部の Linux では、他の C ランタイムを使用しています。 たとえば、Alpine Linux では、マス左を使用します。

Glibc ベースではないコンテナーをジョブコンテナーとして使用する場合は、いくつかの項目を独自に配置する必要があります。 まず、Node.js の独自のコピーを提供する必要があります。 次に、画像にラベルを追加して、Node.js バイナリの場所をエージェントに指示する必要があります。 最後に、株式アルペンには、bash、sudo、groupadd、およびに依存して Azure Pipelines いる他の依存関係もありません。

独自の Node.js を持ち込む

コンテナーにノードバイナリを追加する必要があります。 ノード14は安全な選択肢です。 イメージから開始でき node:14-alpine ます。

エージェントに Node.js について通知する

エージェントは、"com....................................... このラベルが存在する場合は、Node.js バイナリへのパスである必要があります。 たとえば、に基づくイメージでは node:10-alpine 、Dockerfile に次の行を追加します。

LABEL "com.azure.dev.pipelines.agent.handler.node.path"="/usr/local/bin/node"

要件の追加

Azure Pipelines は、一般的な管理パッケージがインストールされている Bash ベースのシステムを前提としています。 特に Alpine Linux には、必要なパッケージがいくつか付属していません。 bash、、およびをインストールする sudo と、 shadow 基本的なニーズに対応できます。

RUN apk add bash sudo shadow

インボックスまたは Marketplace のタスクに依存している場合は、必要なバイナリも指定する必要があります。

Dockerfile の完全な例

FROM node:10-alpine

RUN apk add --no-cache --virtual .pipeline-deps readline linux-pam \
  && apk add bash sudo shadow \
  && apk del .pipeline-deps

LABEL "com.azure.dev.pipelines.agent.handler.node.path"="/usr/local/bin/node"

CMD [ "node" ]

1つのホストされたエージェントにエージェントプールを持つ複数のジョブ

コンテナージョブは、基盤となるホストエージェント Docker config.jsを使用して、イメージレジストリ認証を行います。これは、Docker レジストリコンテナーの初期化の最後に記録されます。 認証のためにシステムに登録されているファイルの Docker config.jsが、並列で実行されている他のいずれかのコンテナージョブによって既にログアウトされているため、後続のレジストリイメージのプル承認が "未承認の認証" で拒否される可能性があります。

このソリューションでは、ホストされて DOCKER_CONFIG いるエージェントで実行されている各エージェントプールサービスに固有の Docker 環境変数を設定します。 DOCKER_CONFIG各エージェントプールの runsvc.sh スクリプトで、をエクスポートします。

#insert anything to set up env when running as a service
export DOCKER_CONFIG=./.docker