1

AKS クラスター上に独自のセルフ ホスト エージェントを作成しました。

Docker のキャッシュを使用するために永続ボリューム (PV) をマウントする StatefulSet を使用して、3 つのレプリカがあります。これは/var/lib/docker、各レプリカのマウントであることを意味します。

すべてがうまくいくまで。

ただし、それagent-0はほとんどの作業をagent-1行いagent-2、作業量は少ないようです。PV-0これは、ほとんどすべての容量を使用しており、そうPV-1でPV-2はないため、問題を引き起こします。

agent-0
/dev/sdc                 98.3G     83.8G     14.5G  85% /var/lib/docker
agent-1
/dev/sdd                 98.3G     35.3G     63.0G  36% /var/lib/docker
agent-2 
/dev/sdc                 98.3G      2.1G     96.2G   2% /var/lib/docker

常に使用するのではなく、負荷がエージェント間で分散されるように、Azure DevOps のパイプラインを制御する方法はありagent-0ますか?

4

3 に答える 3

1

最終的に、docker 内の Docker (dind) から Docker 外の Docker (DooD) に移行するという別のソリューションに行き着きました。

最初に独自の自己ホスト型エージェントを使用したかった主な理由は、ホスト型エージェントを使用して Docker イメージを構築するには時間がかかりすぎるため、Docker レイヤーのキャッシュが必要だったからです。

ある時点で、ARM ベースのイメージをサポートする必要があると判断し、docker buildxの使用を開始したため、docker dind ソリューションを使用するようになりました。

docker.sock をマウントすることによるリスクを認識しています。

Docker コンテナー内から Docker を使用するには、Docker ソケットをバインドマウントする必要があります。これは、セキュリティに非常に深刻な影響を及ぼします。つまり、コンテナー内のコードが Docker ホスト上で root として実行できるようになります。これを実行したい場合は、Docker.com のバインド マウントに関するドキュメントを参照してください。

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#using-docker-within-a-docker-container

しかし、当面はこれで問題は解決します。Pod ごとに PV を管理する必要がなくなり、同じ Docker を使用してすべての非 ARM イメージをビルドするためです。

補足: ARM に関しては、docker イメージをビルドするために docker buildx を実行する別のエージェントを引き続き使用します。

于 2020-04-01T15:41:38.640 に答える
0

常にエージェント 0 を使用するのではなく、負荷がエージェント間で分散されるように Azure DevOps のパイプラインを制御する方法はありますか?

残念ながら、マルチエージェント機能を使用できない場合、ビルド/リリースのワークロードをすべてのエージェントに均等に分散するように制御するすぐに使える方法はありません。

回避策として、パイプライン/ジョブをそれぞれ異なる要求を持つ 3 つに複製することができます。次に、エージェント用に定義されたカスタム機能を設定します。

詳細については、このスレッドを確認してください。

お役に立てれば。

于 2020-03-30T04:03:21.373 に答える