Azure Pipelines・コンテナジョブ・2026年11月5日に確認

Azure Pipelines のコンテナジョブで「Cannot connect to the Docker daemon at unix:///var/run/docker.sock」：エージェント 5.279.0 からの変更と mapDockerSocket

2026年8月28日に出た Azure Pipelines のエージェント 5.279.0 で、mapDockerSocket の既定が false になりました（azure-pipelines-agent #5627）。それまでは、Linux のエージェントのコンテナジョブには、YAML に何も書かなくてもホストの /var/run/docker.sock がジョブのコンテナにマウントされていました。いまは、コンテナのリソースが求めたときだけです。イメージのビルドやテスト用のコンテナの起動のために、コンテナの中から Docker を使うジョブは、パイプラインを何も変えていなくても、新しいエージェントでの最初の実行から失敗します。

エージェントの更新でコンテナジョブが落ちているあいだ：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、落ち始めたビルドのポリシーを、IDE の中でプルリクエストの横に「満たしていない」と出します。JetBrains Marketplace で入れる

見え方

ジョブのコンテナの中の Docker の CLI：Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Testcontainers：「Could not find a valid Docker environment」。apache/flink #29177 では、コンテナジョブの Testcontainers を使うテストがすべてこれで失敗し、毎晩の実行は2026年9月4日から失敗していました。まだ 5.278.0 のセルフホストのエージェントでの実行は通っていて、そのエージェントを上げれば同じように壊れる状態でした。
community.postgresql #948 では、同じ1行を足すまで、このコレクションの Azure Pipelines の実行がすべて失敗していました。
ジョブのコンテナを起動するステップのログで、docker create の行から -v "/var/run/docker.sock":"/var/run/docker.sock" が消えています。apache/flink #29177 は最後に通った実行と最初に失敗した実行を比べ、違いはこのマウントだけでした。

直し方：コンテナのリソースでソケットを求める

Microsoft のコンテナジョブのページにある書き方です。

resources:
  containers:
  - container: my_container
    image: ubuntu:22.04
    mapDockerSocket: true

コンテナの中で Docker を使わないジョブは何もしなくてかまいません。同じページの注意によれば、ソケットを渡すとコンテナの中のコードが Docker のホストで root として動けるので、必要なコンテナにだけ設定します。

または、Docker のステップをホストで動かす

コンテナジョブでも、ステップのターゲットで、ステップ単位でコンテナの外で動かせます。イメージをビルドしてプッシュするだけのステップなら、コンテナの中にソケットはそもそも要りません。

steps:
- script: docker build -t myapp .
  target: host

セルフホストのエージェントが多く、YAML をすぐには直せないとき

同じ Microsoft のページに、エージェントのホストを当面だけ元に戻す方法があります。エージェントに環境変数 AZP_AGENT_DEFAULT_MAP_DOCKER_SOCKET_TO_FALSE=false を設定すると、YAML に mapDockerSocket がない Linux のコンテナジョブには、また /var/run/docker.sock が渡されます。そのエージェントのすべてのコンテナジョブにホストの Docker デーモンをまた渡すことになるので、Microsoft は当面の対策としてだけ使うようにと書いています。

見分け方

「permission denied while trying to connect to the Docker daemon socket」：ソケットはあるのに、コンテナの中のユーザーが使えません。マウントされていないソケットとは別の問題です。
コンテナジョブではなくエージェントの上で直接動くステップには、mapDockerSocket は関係ありません。
パイプラインを変えずに壊れたほかの Linux の変更：Ubuntu 26.04 のイメージではエージェントが runner として動くので、/home/vsts の下のパスが失敗します。
Bitbucket Pipelines では、同じメッセージに別の原因があります：ステップは docker サービスを通してしか Docker に届かない。

IntelliJ IDEA と Rider でのビルド検証

Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。プルリクエストを、ブランチポリシーを平易な文にして IDE のツールウィンドウに並べるので、エージェントの更新の後に落ち始めたビルドのポリシーは、プルリクエストの横に「満たしていない」と出ます。Pro では、失敗したビルドや期限切れのビルドに再実行のリンクが出て、もう一度キューに入れられます。レビューの受信箱とブランチポリシーは無料、投票・コメント・完了・ビルドポリシーの再実行・プルリクの作成は Pro（月 US$1・30日間の無料試用つき）です。画面は日本語です。

JetBrains Marketplace で入れる

Azure DevOps・Azure Pipelines は Microsoft Corporation の商標、Docker は Docker, Inc. の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・Docker, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：Node.js 6・10・16 は2026年11月24日にエージェントから外される · Ubuntu 26.04 の「Access to the path '/home/vsts' is denied」 · ビルド検証：期限切れのビルドと、プルリクのビルドが動かない理由 · English