よく寄せられる質問 - Azure Container Registry

はい。 レジストリを作成するために使用できる[テンプレート](https://azure.microsoft.com/resources/templates/container-registry/)がここにあります。

はい。 Microsoft Defender for Cloud、Twistlock、および Aqua のドキュメントをご覧ください。

[Kubernetes](https://kubernetes.io/docs/user-guide/images/#using-azure-container-registry-acr) のドキュメントおよび [Azure Kubernetes Service](../aks/cluster-container-registry-integration.md) の手順を参照してください。

管理者の資格情報を取得する前に、レジストリの管理者ユーザーが有効になっていることを確認してください。

Azure CLI を使用して資格情報を取得するには:

az acr credential show -n myRegistry

Azure PowerShell の使用:

Invoke-AzureRmResourceAction -Action listCredentials -ResourceType Microsoft.ContainerRegistry/registries -ResourceGroupName myResourceGroup -ResourceName myRegistry

管理者の資格情報を取得する前に、レジストリの管理者ユーザーが有効になっていることを確認してください。

最初のパスワードを取得するには:

{
    "password": "[listCredentials(resourceId('Microsoft.ContainerRegistry/registries', 'myRegistry'), '2017-10-01').passwords[0].value]"
}

2 番目のパスワードを取得するには:

{
    "password": "[listCredentials(resourceId('Microsoft.ContainerRegistry/registries', 'myRegistry'), '2017-10-01').passwords[1].value]"
}

このエラーは、ユーザーがレジストリに対するアクセス許可を持っているが、サブスクリプションに対する閲覧者レベルのアクセス許可を持っていない場合に表示されます。 この問題を解決するには、ユーザーにサブスクリプションに対する閲覧者アクセス許可を割り当てます。

az role assignment create --role "Reader" --assignee user@contoso.com --scope /subscriptions/<subscription_id> 

ファイアウォール規則の変更が反映されるまで時間がかかります。 ファイアウォールの設定を変更した後は、この変更を検証する前に、数分間お待ちください。

ACR は Docker Registry HTTP API V2 をサポートしています。 これらの API には `https:///v2/` でアクセスできます。 例: https://mycontainerregistry.azurecr.io/v2/

Bash を使用している場合:

az acr manifest list-metadata --name myRepository --registry myRegistry --query "[?tags[0]==null].digest" --output tsv  | xargs -I% az acr repository delete --name myRegistry ---image myRepository@%

PowerShell の場合:

az acr manifest list-metadata --name myRepository --repository myRegistry --query "[?tags[0]==null].digest" --output tsv | %{ az acr repository delete --name myRegistry --image myRepository@$_ }

詳細については、「[Azure Container Registry のコンテナー イメージを削除する](container-registry-delete.md)」を参照してください。

この状況は、基になるレイヤーが引き続き他のコンテナー イメージによって参照されている場合に発生することがあります。 参照されていないイメージを削除した場合、レジストリの使用量は数分以内に更新されます。

次の docker ファイルを使用して、1GB のレイヤーを持つイメージを作成します。 これにより、このイメージには、レジストリ内の他のどのイメージからも共有されないレイヤーが確実に含まれます。

FROM alpine
RUN dd if=/dev/urandom of=1GB.bin  bs=32M  count=32
RUN ls -lh 1GB.bin

docker CLI を使用して、このイメージを構築してレジストリにプッシュします。

docker build -t myregistry.azurecr.io/1gb:latest .
docker push myregistry.azurecr.io/1gb:latest

Azure Portal でストレージの使用量が増加したことを確認できるか、または CLI を使用して使用量にクエリを実行できます。

az acr show-usage -n myregistry

Azure CLI またはポータルを使用してイメージを削除し、数分以内に更新された使用量を確認します。

az acr repository delete -n myregistry --image 1gb

Docker ソケットをマウントすることによって Azure CLI コンテナーを実行する必要があります。

docker run -it -v /var/run/docker.sock:/var/run/docker.sock azuresdk/azure-cli-python:dev

コンテナーで、`docker` をインストールします。

apk --update add docker

次に、レジストリに対して認証します。

az acr login -n MyRegistry

最新の docker クライアント (バージョン 18.03.0 以上) を使用して TLS 1.2 を有効にします。

はい。[Docker Notary](https://docs.docker.com/notary/getting_started/) が統合されており、これを有効にできるため、Azure Container Registry で信頼済みのイメージを使用できます。 詳細については、「[Azure Container Registry におけるコンテンツの信頼](container-registry-content-trust.md)」を参照してください。

サムプリント用のファイルはどこにありますか?

`~/.docker/trust/tuf/myregistry.azurecr.io/myrepository/metadata` の下:

• 委任ロールを除くすべてのロールの公開キーと証明書は `root.json` に格納されています。
• 委任ロールの公開キーと証明書は、その親ロール (`targets/releases` ロールの場合の `targets.json` など) の JSON ファイルに格納されています。

Docker および Notary クライアントによって全体的な TUF の検証が行われた後、これらの公開キーと証明書を確認することをお勧めします。

ACR は、さまざまなレベルのアクセス許可を提供する[カスタム ロール](container-registry-roles.md)をサポートしています。 具体的には、`AcrPull` および `AcrPush` ロールを使用すると、ユーザーは Azure でレジストリ リソースを管理するためのアクセス許可なしで、イメージのプルまたはプッシュ、あるいはその両方を行うことができます。

• Azure portal: レジストリ -> [アクセス制御 (IAM)] -> [追加] (ロールの AcrPull または AcrPush を選択)。

• Azure CLI:次のコマンドを実行して、レジストリのリソース ID を見つけます。

  az acr show -n myRegistry
  

  その後、ユーザーに `AcrPull` または `AcrPush` ロールを割り当てることができます (次の例では `AcrPull` を使用しています)。

  az role assignment create --scope resource_id --role AcrPull --assignee user@example.com
  

  または、そのアプリケーション ID で識別されたサービス プリンシパルにロールを割り当てます。

  az role assignment create --scope resource_id --role AcrPull --assignee 00000000-0000-0000-0000-000000000000
  

それにより、アサイニーは、レジストリ内のイメージの認証やアクセスが可能になります。

• レジストリを認証するには:

  az acr login -n myRegistry 
  

• リポジトリを一覧表示するには:

  az acr repository list -n myRegistry
  

• イメージをプルするには:

  docker pull myregistry.azurecr.io/hello-world
  

`AcrPull` または `AcrPush` ロールを使用しただけでは、アサイニーに Azure でレジストリ リソースを管理するためのアクセス許可は与えられません。 たとえば、`az acr list` または `az acr show -n myRegistry` でレジストリは表示されません。

イメージの検疫は現在、ACR のプレビュー機能です。 セキュリティ スキャンに正常に合格したイメージのみが通常のユーザーに表示されるように、レジストリの検疫モードを有効にすることができます。 詳細については、[ACR の GitHub リポジトリ](https://github.com/Azure/acr/tree/master/docs/preview/quarantine)に関するページを参照してください。

詳細については、レジストリ コンテンツの公開に関するページを参照してください。

マニフェスト内の非再頒布可能レイヤーには、コンテンツのフェッチ元となる可能性がある URL パラメーターが含まれています。 非再頒布可能レイヤーのプッシュを有効にするユース ケースとしては、ネットワーク制限付きレジストリ、アクセス制限のあるエアギャップ レジストリ、またはインターネット接続のないレジストリが考えられます。

たとえば、VM によるイメージのプルをお使いの Azure コンテナー レジストリからのみ実行できるように NSG 規則を設定している場合、Docker では、外部または非再頒布可能レイヤーのプル エラーが発生します。 たとえば、Windows Server Core イメージには、マニフェスト内の Azure コンテナー レジストリへの外部レイヤー参照が含まれており、このシナリオではプルは失敗します。

非再頒布可能レイヤーのプッシュを有効にするには:

1. `daemon.json` ファイルを編集します。これは、Linux ホストでは `/etc/docker/` に、Windows Server では `C:\ProgramData\docker\config\daemon.json` にあります。 これまでファイルが空であったと仮定して、次の内容を追加します。

   {
     "allow-nondistributable-artifacts": ["myregistry.azurecr.io"]
   }
   

   Note

   値は、コンマで区切られたレジストリ アドレスの配列です。

2. ファイルを保存して終了します。

3. Docker を再起動します。

一覧のレジストリにイメージをプッシュすると、非再頒布可能レイヤーがレジストリにプッシュされます。

環境とレジストリに関する一般的な問題のトラブルシューティングを行うには、「[Azure コンテナー レジストリの正常性のチェック](container-registry-check-health.md)」を参照してください。

• このエラーが一時的な問題である場合は、再試行が成功します。
• `docker pull` が引き続き失敗する場合は、Docker デーモンの問題である可能性があります。 この問題は一般に、Docker デーモンを再起動することによって緩和されます。
• Docker デーモンを再起動してもこの問題が引き続き表示される場合は、コンピューターとの何らかのネットワーク接続の問題である可能性があります。 コンピューター上の一般的なネットワークが正常かどうかを確認するには、次のコマンドを実行してエンドポイントの接続性をテストします。 この接続チェック コマンドを含む最小の`az acr` バージョンは、2.2.9 です。 以前のバージョンを使用している場合は、Azure CLI をアップグレードしてください。

az acr check-health -n myRegistry

• すべての Docker クライアント操作に対して常に再試行メカニズムを用意する必要があります。

お使いのコンピューターのネットワーク ダウンロード速度をテストするには、速度ツールを使用します。 コンピューター ネットワークが遅い場合は、レジストリと同じリージョンで Azure VM を使って、ネットワーク速度を改善することを検討してください。

お使いのコンピューターのネットワーク アップロード速度をテストするには、速度ツールを使用します。 コンピューター ネットワークが遅い場合は、レジストリと同じリージョンで Azure VM を使って、ネットワーク速度を改善することを検討してください。

このエラーは、`--signature-verification` が既定で有効になっている Red Hat バージョンの Docker デーモンで発生する場合があります。 次のコマンドを実行して、Red Hat Enterprise Linux (RHEL) または Fedora の Docker デーモン オプションを確認できます。

grep OPTIONS /etc/sysconfig/docker

たとえば、Fedora 28 Server には次の docker デーモン オプションがあります。

OPTIONS='--selinux-enabled --log-driver=journald --live-restore'

`--signature-verification=false` がないと、`docker pull` は次のようなエラーで失敗します。

Trying to pull repository myregistry.azurecr.io/myimage ...
unauthorized: authentication required

このエラーを解決するには:

1. Docker デーモンの構成ファイル `/etc/sysconfig/docker` にオプション `--signature-verification=false` を追加します。 次に例を示します。

   OPTIONS='--selinux-enabled --log-driver=journald --live-restore --signature-verification=false'

2. 次のコマンドを実行して、Docker デーモン サービスを再起動します。

   sudo systemctl restart docker.service
   

`--signature-verification` の詳細は、`man dockerd` を実行して確認できます。

レジストリ リソース名が大文字であるか、`myRegistry` のように大文字と小文字が混在している場合でも、`docker push myregistry.azurecr.io/myimage:latest` のように、サーバー URL にはすべて小文字を使用してください。

`debug` オプションを使用して `dockerd` を起動します。 最初に、Docker デーモンの構成ファイル (`/etc/docker/daemon.json`) が存在しない場合は作成し、`debug` オプションを追加します。

{    
    "debug": true    
}

次に、このデーモンを再起動します。 たとえば、Ubuntu 14.04 では次のようにします。

sudo service docker restart

詳細は、[Docker のドキュメント](https://docs.docker.com/engine/admin/#enable-debugging)で見つけることができます。

• ログは、システムに応じて異なる場所に生成される可能性があります。 たとえば、Ubuntu 14.04 では `/var/log/upstart/docker.log` です。
  詳細については、[Docker のドキュメント](https://docs.docker.com/engine/admin/#read-the-logs)を参照してください。

• Docker for Windows の場合、ログは %LOCALAPPDATA%/docker/ の下に生成されます。 ただし、すべてのデバッグ情報はまだ含まれていない可能性があります。

  完全なデーモン ログにアクセスするために、追加の手順がいくつか必要になる場合があります。

  docker run --privileged -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /usr/local/bin/docker:/usr/local/bin/docker alpine sh
  
  docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh
  chroot /host
  

  これで、`dockerd` を実行している VM のすべてのファイルにアクセスできます。 ログは `/var/log/docker.log` にあります。

サービス プリンシパルに新しいアクセス許可 (新しいロール) を付与した場合は、その変更が直ちに有効にならない可能性があります。 次の 2 つの原因が考えられます。

• Microsoft Entra のロール割り当ての遅延。 これは通常は高速ですが、伝播の遅延のために数分かかることがあります。

• ACR トークン サーバーでのアクセス許可の遅延に、最大 10 分かかる場合があります。 これを緩和するには、`docker logout` を実行し、1 分後に同じユーザーで再び認証することができます。

  docker logout myregistry.azurecr.io
  docker login myregistry.azurecr.io
  

ACR は現在、ユーザーによるホーム レプリケーションの削除をサポートしていません。 対処法として、テンプレートにホーム レプリケーションの作成を含めますが、次に示すように `"condition": false` を追加することによってその作成をスキップします。

{
    "name": "[concat(parameters('acrName'), '/', parameters('location'))]",
    "condition": false,
    "type": "Microsoft.ContainerRegistry/registries/replications",
    "apiVersion": "2017-10-01",
    "location": "[parameters('location')]",
    "properties": {},
    "dependsOn": [
        "[concat('Microsoft.ContainerRegistry/registries/', parameters('acrName'))]"
     ]
},

特に (リダイレクトをフォローするために) オプション `-L`、`--location` を指定して `curl` ツールを使用すると、`InvalidAuthenticationInfo` エラーが発生する場合があります。 たとえば、`-L` オプションを指定した `curl` と基本認証を使用して BLOB をフェッチすると、

curl -L -H "Authorization: basic $credential" https://$registry.azurecr.io/v2/$repository/blobs/$digest

次の応答が返される場合があります。

<?xml version="1.0" encoding="utf-8"?>
<Error><Code>InvalidAuthenticationInfo</Code><Message>Authentication information is not given in the correct format. Check the value of Authorization header.
RequestId:00000000-0000-0000-0000-000000000000
Time:2019-01-01T00:00:00.0000000Z</Message></Error>

この根本原因は、一部の `curl` 実装では元の要求のヘッダーを使用してリダイレクトをフォローするためです。

この問題を解決するには、ヘッダーなしで手動でリダイレクトをフォローする必要があります。 `curl` の `-D -` オプションを使用して応答ヘッダーを印刷した後、`Location` ヘッダーを抽出します。

REDIRECT_URL=$(curl -s -D - -H "Authorization: basic $credential" https://$registry.azurecr.io/v2/$repository/blobs/$digest | grep "^Location: " | cut -d " " -f2 | tr -d '\r')
curl $REDIRECT_URL

Microsoft Edge または IE ブラウザーを使用している場合は、最大で 100 個のリポジトリまたはタグを表示できます。 レジストリに 100 を超えるリポジトリまたはタグが含まれている場合は、すべてを一覧表示するために Firefox または Chrome ブラウザーを使用することをお勧めします。

ブラウザーがリポジトリまたはタグをサーバーにフェッチするための要求を送信できない可能性があります。 次のような理由が考えられます。

• ネットワーク接続の不備
• ファイアウォール
• プライベート アクセスのみを許可するレジストリに対する、公衆ネットワークからのポータルの使用
• 広告ブロッカー
• DNS エラー

ネットワーク管理者に問い合わせるか、ネットワークの構成と接続を確認してください。 Azure CLI を使用して `az acr check-health -n yourRegistry` を実行し、ご使用の環境から Container Registry に接続できるかどうかを確認します。 また、ブラウザーでシークレット/プライベート セッションを試して、古いブラウザー キャッシュや Cookie を回避することもできます。

操作が許可されない可能性のあるいくつかのシナリオを次に示します。

• クラシック レジストリはサポートされなくなりました。 [az acr update](/cli/azure/acr#az_acr_update) か Azure portal を使用して、サポートされている[サービス レベル](./container-registry-skus.md)にアップグレードしてください。
• イメージやリポジトリがロックされているため、削除や更新を実行できない場合があります。 az acr repository show コマンドを使用して、現在の属性を表示できます。
• イメージが検疫状態の場合、一部の操作は許可されません。 検疫の詳細については、[こちら](https://github.com/Azure/acr/tree/master/docs/preview/quarantine)をご覧ください。
• レジストリが、その[ストレージの上限](container-registry-skus.md#service-tier-features-and-limits)に達した可能性があります。

リポジトリの操作でリポジトリ名を指定するときに "サポートされていないリポジトリ形式"、"無効な形式"、"要求されたデータが存在しません" などのエラーが表示された場合は、名前のスペル、および大文字か小文字かを確認します。 有効なリポジトリ名には、小文字の英数字、ピリオド、ダッシュ、アンダースコア、およびスラッシュのみを含めることができます。

前提条件

• Fiddler で HTTPS の復号化を有効にします。
• Docker UI を使用して、Docker によるプロキシの使用を有効にします。
• 完了したら必ず元に戻してください。 これが有効になっていて、Fiddler が実行されていない場合、Docker は機能しません。

Windows コンテナー

Docker プロキシを 127.0.0.1:8888 に構成します。

Linux コンテナー

Docker VM 仮想スイッチの IP を見つけます。

(Get-NetIPAddress -InterfaceAlias "*Docker*" -AddressFamily IPv4).IPAddress

Docker プロキシを前のコマンドの出力とポート 8888 に構成します (たとえば、10.0.75.1:8888)。

次のコマンドは、指定されたレジストリ内のすべての実行中のタスクを取り消します。

az acr task list-runs -r $myregistry --run-status Running --query '[].runId' -o tsv \
| xargs -I% az acr task cancel-run -r $myregistry --run-id %

`az acr build` コマンドにローカルのソース フォルダーを渡した場合、既定では、`.git` フォルダーはアップロードされるパッケージから除外されます。 次の設定を使用して、`.dockerignore` ファイルを作成できます。 これは、コマンドに、アップロードされるパッケージ内の `.git` の下にあるすべてのファイルを復元するよう指示します。

!.git/**

この設定は、`az acr run` コマンドにも適用されます。

現在、ソース トリガーに対して GitLab はサポートされていません。

実行のエラー メッセージのトラブルシューティング

CI/CD の統合

• [CircleCI](https://github.com/Azure/acr/blob/master/docs/integration/CircleCI.md)
• GitHub のアクション

既存のネットワーク セキュリティ グループまたはユーザー定義ルートに、正しいファイアウォール規則を設定します。 セットアップの後、ファイアウォール規則が適用されるまで数分待ちます。

次の Azure の組み込みポリシーでは、それぞれのポリシーの状態に設定すると、ユーザーがレジストリで管理者ユーザーを有効にできなくなります。

次のステップ

• Azure Container Registry の[詳細を学習](container-registry-intro.md)します。