标签: azure-container-registry

我创建了一个 Azure 容器注册表，并将自定义 ACI 上传到注册表 - 没问题 - 一切都按预期工作。我曾尝试使用 Azure 门户从映像创建容器实例，也没有任何问题 - 但是 - 当我想使用 C# 和 Microsoft Azure 管理容器实例 Fluent API 自动化操作时，我遇到了问题，即使我感觉自己一直在上网和设置，寻找隐藏的障碍物，一直没能找到多少帮助。

我的代码如下：

var azureCredentials = new AzureCredentials(new
ServicePrincipalLoginInformation
{
    ClientId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    ClientSecret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}, "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
AzureEnvironment.AzureGlobalCloud);

var azure = Azure
    .Configure()
    .Authenticate(azureCredentials)
    .WithSubscription("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx");

IContainerGroup containerGroup = azure.ContainerGroups.Define("mytestgroup")
    .WithRegion(Region.EuropeWest)
    .WithExistingResourceGroup("mytest-rg")
    .WithLinux()
    .WithPrivateImageRegistry("mytestreg.azurecr.io", "mytestreg", "xxxxxxxxxxxxxx")
    .WithoutVolume()
    .DefineContainerInstance("mytestgroup")
    .WithImage("mytestimage/latest")
    .WithExternalTcpPort(5555)
    .WithCpuCoreCount(.5)
    .WithMemorySizeInGB(.5)
    .Attach()
    .Create();

上面的代码不断给我异常：

Microsoft.Rest.Azure.CloudException: 'The image 'mytestimage/latest' in container group 'mytestgroup' is not accessible. Please check the …

我在Azure中部署了一个Linux应用服务,使用来自私有Azure容器注册表的映像.

服务正常运行,尽管没有对映像进行任何更改(没有新的推送),但App Service已经重新部署.我理解这是Azure如何处理容器,在其认为合适时交换实例的预期部分.

但是,此映像不再能够成功部署,以下是来自Kudu的日志(名称已更改):

2018-04-09 07:28:11.817 INFO  - Starting container for site 
2018-04-09 07:28:11.818 INFO  - docker run -d -p 36165:8080 --name my-service_0 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=8080 -e WEBSITE_SITE_NAME=my-service -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -e HTTP_LOGGING_ENABLED=1 myacr.azurecr.io/images/my-image:latest  

2018-04-09 07:28:14.200 INFO  - Issuing docker pull myacr.azurecr.io/images/my-image:latest 
2018-04-09 07:28:14.327 ERROR - docker pull returned STDERR>> Error response from daemon: Get https://myacr.azurecr.io/v2/images/my-image/manifests/latest: unauthorized: authentication required

以下是在本地提取图像的结果:

docker pull myacr.azurecr.io/images/my-image:latest
latest: Pulling from images/my-image 
53478ce18e19: Already exists 
d1c225ed7c34: Already exists 
c6724ba0c09a: Already exists …

我想删除 Azure 容器注册表中除最后两个之外的所有映像。我正在寻找一个脚本来执行此操作，但我发现只能删除 X 天之前的图像。这对于我的情况来说是不可能的，因为有时会创建很多图像，而有时则只创建一张图像。

有人有什么想法吗？

在尝试docker login使用 Active Directory 凭据通过命令登录 Azure 容器注册表时，我遇到了以下问题：

Error response from daemon: Get https://myregistry.azurecr.io/v2/: unauthorized: authentication required

很明显，权限存在问题，但我找不到达到目标的正确方法。

请注意：

az acr login --name myregistry工作得很好，之后我可以上传我的图像，但由于特定情况，我需要一个docker login带有 AD 凭据的命令和身份验证解决方案。

我尝试使用以下文档向用户提供所需的权限 acrpull/acrpush/acrdelete：

https://docs.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal

但没有运气 - 相同的输出。

有什么方法可以使用 AD 凭据登录 ACRdocker login吗？

将映像部署到 AKS 实例时，从 ACR（高级 SKU）提取映像的速度非常慢，即使是大小约为 150 MB 左右的“小”映像也是如此。

AKS 资源和 ACR 资源均位于加拿大东部地区。

这是一个例子：

root@076fff2831b2:/tmp# kubectl describe pod application-service-59bcf96874-pvrmb
Name:           application-service-59bcf96874-pvrmb
Namespace:      default
Priority:       0
Node:           aks-41067869-1/10.255.13.163
Start Time:     Tue, 11 Feb 2020 18:15:53 -0500
Labels:         app.kubernetes.io/instance=application-service
                app.kubernetes.io/name=application-service
                pod-template-hash=59bcf96874
Annotations:    <none>
Status:         Running
IP:             10.255.13.175
IPs:            <none>
Controlled By:  ReplicaSet/application-service-59bcf96874
Containers:
  application-service:
    Container ID:   docker://0e86526a293d9055d482a09f043f0be68c594244fe4216f8fb190bc2caf6b65b
    Image:          myacr01.azurecr.io/microservices/application-service:0.0.6
    Image ID:       docker-pullable://myacr01.azurecr.io/microservices/application-service@sha256:cfbb3ffa7adc52da9cc0b8d7f78376076ea712025b59df8e406c559d369f4085
    Port:           3000/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 11 Feb …

我正在尝试使用 Visual Studio 2019 将我的 .Net core 应用程序 docker 映像发布到 Azure 容器注册表。

它工作正常，但突然我开始看到以下错误：

发布遇到错误。运行 docker.exe 登录命令失败。

警告！通过 CLI 使用 --password 是不安全的。使用 --password-stdin。来自守护程序的错误响应：获取https://app.azurecr.io:443/v2/：未经授权：需要身份验证

诊断日志已写入以下位置：“C:\Users\user\AppData\Local\Temp\tmp768.tmp”

当运行以下CMD命令时：

docker login https://app.azurecr.io

我正进入（状态：

正在使用现有凭据进行身份验证...

登录成功

我重新启动了 Visual Studio 和 Docker，并且以管理员身份运行 Visual Studio。

有人遇到过类似的问题吗？

我们已经开始将产品从这一庞大的整体中剥离到 Azure 中。产品也可以称为微服务。

我们有一个问题 - 我们应该有一个 Azure 容器注册表 (ACR) 来服务所有不同的产品，还是每个产品都应该有自己的 ACR？我们仅讨论开发订阅。在生产中，我们计划拥有一个不同的 ACR 或一组 ACR，图像将从开发中导入到其中。

但问题是——推荐的方式是什么？如果我们将 ACR 视为一件人工制品，那么一个就足够了。毕竟，我们只有一个 Azure Artifacts 实例（具有多个不同的源），用于推送 nuget 包。nuget 包和 docker 镜像都是构建工件，因此有一种观点认为，如果我们只有一个 nuget 工件，为什么还要有多个 ACR？

另一方面，对于 Azure Artifacts，我们实际上没有选择 - 只有一个选择。因此，也许我们错过了一些可以通过拥有多个 ACR 来实现甚至期望的有效场景。

我正在按照官方文档中的说明进行操作

执行命令时：

az acr build --registry <container_registry_name> --image webimage

我正在接收

需要以下参数：<SOURCE_LOCATION>

但根据文档，<SOURCE_LOCATION> 不是必需参数。

有人遇到过这样的案例吗？

根据ACA 文档，我们必须指定容器的目标端口

az containerapp create \
  --name my-container-app \
  --resource-group $RESOURCE_GROUP \
  --environment $CONTAINERAPPS_ENVIRONMENT \
  --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \
  --target-port 80 \
  --ingress 'external' \
  --query configuration.ingress.fqdn

现在我的问题是如何通过 docker-compose 部署而不仅仅是单个图像，因为有一个目标端口？

如果我在 ACR 存储库中有以下标签和清单...

当我运行以下命令时，它会返回以下内容...

az acr repository show-manifests --name "[registry-name]" --repository "[repository-name]"

[
  {
    "digest": "sha256:30be2b07e723b0f36fed370c386b027e52dbcd0ad2ad2fcac1d3b7d1b361292f",
    "tags": [
      "982878",
      "master"
    ],
    "timestamp": "2022-09-07T15:49:04.4187041Z"
  }
]

当我运行以下清除命令时......

az acr run --cmd "acr purge --filter '[repository-name]:.*' --untagged --ago 1m" --registry [registry-name] /dev/null

它正在删除标签和清单，并且因为它删除了所有内容，所以存储库也被删除。

为什么当我使用该标志时它会这样做，--untagged并且您可以清楚地看到它没有根据起始状态取消标记？